← Back to team overview

kicad-developers team mailing list archive

Re: Fwd: file format feedback

 

Le 09/04/2012 17:37, Wayne Stambaugh a écrit :
On 4/9/2012 9:50 AM, Dick Hollenbeck wrote:

Wayne, regarding:

DRAWSEGMENT::Format(), it concerns me in two minor ways:

     case S_SEGMENT:  // Line
         aFormatter->Print( 0, "line (pts xy(%s) xy(%s))",
                            FormatBIU( m_Start ).c_str(),
                            FormatBIU( m_End ).c_str() );


a) I don't think this is s-expression, the xy(...) should be (xy ...)


b) It may be worth considering losing one token, namely the "(draw line"  might be
"(gr_line".  (Really, I am just trying to cover my ass.)  I don't want to be blamed for
the slow parsing speed later.   :)   Any reduction in another token that is simple like
this is worth considering.  Each token in the stream is another delay, which cumulatively
may be noticeable.   Maybe a common prefix for the graphic primitives in this
DRAWSEGMENT::Format() would allow you to omit one token.

Suggesting "gr_" or something like it prefixed to the primitive, instead of a full token
"draw ".  My concern is speed later.   However, I'm guessing you are reserving the right
to makes changes later.  :)


I'm guessing it really gets important on the more common objects like tracks and vias,
*especially tracks*, which end up being about the most common object in the file.


ALSO:
==========

Maybe we can get the (track...) on one line as a default, this will help also, since we're using two lines now.

Whitespace in this format is not supposed to matter, but again, I am trying to get out of the way regarding parsing speed later.

As of now, the deepest indentation level is 6 spaces.  I know the
indentation is responsible for a lot of the additional file size but
getting rid of it would seriously reduce the readability file.  I'm not
sure there is an elegant solution to that problem.

Wayne

Yes, tracks are the most common object in the file.
In fact, track is the single object that really needs to be optimized in file.
(I have boards with more than 120 000 tracks)
In order to reduce the time to read (or write) the brd file, an option could be do not repeat some parameters
if they do not change.
Mainly track width and track layer values could use the last value read.
So consecutive tracks having the same width and layer (very common in Pcbnew) need only 2 parameters (Y and Y coordinates),
This trick is often used in many applications.


--
Jean-Pierre CHARRAS



Follow ups

References