kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/25/2012 1:50 AM, Dick Hollenbeck wrote:
> On 10/24/2012 03:50 PM, Wayne Stambaugh wrote:
> > On 10/24/2012 3:01 PM, Dick Hollenbeck wrote:
> > > Wayne,
> > >
> > > I am seeing very slow operation of said function even in Release build mode.
> > > Its bad enoughto warrant some study, maybe we can find a bottle neck.
> > > We might need to run some performance analyzer on it find out where the time is going.
> > >
> > > Please test with the biggest board you can find.
> > >
> > > Thanks for any help you can offer on this,
> > >
> > > Dick
> > Dick,
> >
> > I wonder if this has anything to do with the fact that I used
> > wxFileOutputStream instead of wxFFile.  It's possible the overhead of
> > the output stream is causing the performance problems but you wouldn't
> > think so.
>
>
> Yep, that was it.  I wrote new class FILE_OUTPUTFORMATTER and it is  10 times faster than
> STREAM_OUTFORMATTER for file streams.  STREAM_OUTPUTFORMATTER is now far less useful,
> perhaps only for writing to a zip file or socket, or something purely academic that will
> never happen.

I wouldn't have guessed that it would be that much of a difference.  Go 
figure.  We should probably do a global search and replace of any other 
instances of wxFileOutputStream.  If memory serves, I seem to remember 
it being used in other places.

Wayne

> Inside the virtual write() overload, it simply calls fwrite() which does the newline
> translation if the file is on windows and opened in text mode.
>
> Consider this now fixed.  Thanks for the idea, although I did not use wxFFile, simply
> FILE*.   (No need to trust wx for the basics, as we've just seen.)
>
>
> Dick
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp