← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #07886

Re: Fwd: file format feedback

  Thread Previous • Date Previous • • Thread Next 
Le 10/04/2012 01:23, Wayne Stambaugh a écrit :

On 4/9/2012 2:41 PM, jean-pierre charras wrote:

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.



This could be a nifty optimization.  Are the track objects currently
sorted?  This would need to done to maximize this optimization.



Tracks are currently sorted by net and then by proximity.
So net code (and/or net name) should be output only once.
Inside a given net, most of tracks have the same width,
so width parameter should be rarely needed.

format like:
(tracks
  (net 1)
  (track(xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) (layer 0))
  (track (xy 91.6686 81.8134) (xy 101.6686 85.4837))
  (via (xy 101.6686 85.4837) (size 1.6096) (layerspair back front))
or:   (via thru (at 0.082 0.038) (size 0.08))

  (track ... )
  ( via (xy 129.6686 95.4837) (size 1.6096) )
  (net 2)
  ...
  )
)

or something like sounds good for me.

blind/buried vias need a layerspair definition.
through vias do not need this parameter.

Note also to minimize time in some search functions, tracks and vias are "sorted" by proximity
and the track/via order in list should not be modified.


--
Jean-Pierre CHARRAS

Follow ups

References

  Thread Previous • Date Previous • • Thread Next