kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/9/2012 2:37 PM, Dick Hollenbeck wrote:
> On 04/09/2012 10:45 AM, Wayne Stambaugh wrote:
>> On 4/9/2012 10:38 AM, Dick Hollenbeck wrote:
>>> Some more feedback:
>>>
>>> (segment ...) IS on one line, so good there.
>>>
>>> Wonder if (segment) is our best keyword for what is a trace/track.  specctra uses
>>> (wire).   Could check EAGLE's new XML format, if we're lacking opinions, which would be
>>> atypical.
>>>
>>>
>>> Wonder of the flags in (segment (status HERE) )  should not be spelled out, and omitted
>>> when they are defaulted.  This way you can omit (status).
>> Spelling out the flags is doable.  I was also wondering which flags
>> actually need to be saved.
> 
> Exactly, you got my hidden point too.  :)

I figured as much.  I'm going to have to lean on you and JP while I get
up to speed on the Pcbnew code base.

> 
>>   I'm sure some of the editing flags don't
>> need to be saved.  But they may all be cleaned up properly before the
>> file is saved so it may be a non-issue.
> 
> Even as bits, they could have set/get accessors which can hide where they live even in the
> Format() and subsequent parser.
> 
> 
> Back to speed:
> 
> 
> Tokens '(' and ')' are obviously MUCH faster than looking up a keyword, and this is why
> this format is going to kick the pants off of any XML format for loading speed.
> 
> 
> So I would think we should score these ( and ) as 5% tokens, speed-wise.    And when we
> add the hash-table support to DSNLEXER, I think the KICAD_PLUGIN loader has a chance of
> being nearly as fast as the LEGACY_PLUGIN loader.
> 
> 
> I am lobbying now for fast support of these really huge board design files I sometimes
> hear about.   I have heard rumors of 40 mbyte board design files among our user base. 
> This is the BOARD design file I am concerned about.  Not the 90% under the fat part of the
> bell curve.  Some of these huge files are allegedly taking several minutes to load in the
> commercial board software packages.
> 
> Not so here, watch us.
> 

Once we get the reader working, it would be nice to get a board file
this size to do some performance testing.  The video demo board is the
biggest board file that I have access to.