kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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'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.