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(). _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
