kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/09/2012 10:37 AM, Wayne Stambaugh wrote:
> 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


File size is no problem for me.  I don't see it being too tied to speed.  All my comments
in this sub-thread were purely *speed* centered, speed only.

Eliminating an fgets() ( DSNLEXER::ReadLine() )  for each TRACK, gives me a running start
on the speed comparison which will be inevitable.

So my concern was NOT the 6 spaces, I don't see that as significant.  But rather the fgets().