kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

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