kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/09/2012 01: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.


The TRACK::Format() function has little to no access to context from its neighbor, and we
added this Format() member function to the board object classes, just as we are TAKING OUT
member functions Save() and ReadDescr() which were for legacy format. 


The difference is CLIPBOARD support (which s-expression format is also intended for). 
Clipboard support argued for promotion of Format() to special "member" status, and the
others were DEMOTED to no special status, just as you might have no special status in
saving to EAGLE format in that upcoming PLUGIN.


The s-expression format was supposed to be self-describing, and be just as valid on the
clipboard as in a file.  If now it needs to be augmented with contextual information about
a layer, this is a bit of a ruffle, but not fatal.  This is part of why we have the
"aControl" argument in the Format() function, un-expected needs.  (The only thing you
expect is that you will have un-expected needs.)


What I suggest is to code first then optimize later, if its necessary at all (to
optimize).  We have the timing instrumentation function now, so we can measure what we've got.

The DSNLEXER hash-table is a big hammer, and memory allocation is a big hammer.  The
bottleneck is more likely to be in "new OBJECT" as anywhere else.


Dick