kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.