On 4/9/2012 2:28 PM, Dick Hollenbeck wrote: > 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(). >
We may be able to apply grouping here as well. Something like: (traces (xy 91.6686 85.4837) (xy 91.6686 81.8134) (width 0.6096) (layer 0) (net 1)) ) may speed things up a bit. It would require sorting vias and traces so they could be grouped properly. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
