On Thu, Jul 2, 2015 at 11:39 PM, Jan Blizničenko <blizn...@fit.cvut.cz>
wrote:
> Flush is, in the store benchmark I used, called from from
> MultiByteFileStream(WriteStream) >>#nextChunkPut: and from
> CompiledMethod>>#putSource:inFile:withPreamble: ... when I comment out
> calling flush in these two methods, it is fast like when whole content of
> flush method is commented out. However, If I keep these two flush calls
> commented, but I once call flush manually in the end of the "store" code,
> it
> is slow again (well, instead of 8-18 runs per sec it runs 40-50 times per
> sec, but it is far from 9000 when flush does not happen at all). It seems
> to
> me like the problem is not in how many times flush is called, but more in
> what actually happens when flush is called (how is the primitive primFlush:
> achieved on Windows).
>
In pharo-vm\platforms\win32\plugins\FilePlugin\sqWin32FilePrims.c
sqInt sqFileFlush(SQFile *f) {
if (!sqFileValid(f))
FAIL();
/* note: ignores the return value in case of read-only access */
FlushFileBuffers(FILE_HANDLE(f));
return 1;
}
http://blogs.msdn.com/b/oldnewthing/archive/2010/09/09/10059575.aspx
"If you perform one of these explicit flush operations, you aren't letting
the disk cache do its job."
I guess we do just that.
More on that issue:
http://stackoverflow.com/questions/18276554/windows-fsync-flushfilebuffers-performance-with-large-files
http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-application-developers/
Side question: is write caching enabled on that drive?
Phil
>
> Jan
>
>
> Nicolai Hess wrote
> > 2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe <
>
> > sven@
>
> > >:
> >
> >> #flush on a stream means pushing all data to the final destination,
> >> clearing buffers, doing actual network transfers.
> >>
> >> What can happen when you disable that ?
> >>
> >> That some data does not arrive where it should I guess.
> >>
> >> Mind that #close most of the time does an automatic/implicit #flush.
> >>
> >> Anyway, I don't think disabling #flush is a real solution.
> >>
> >
> > +1
> >
> > Maybe it is enough, if we remove the call to "self flush" in
> > WriteStream>>#nextChunkPut:
> > ?
> >
> > I see that squeak does not call flush, and :) in Squeak
> > WriteStream>>#flush
> > is empty (!)
> > (But I think in squeak and pharo are many differences for stream and
> > source/changes handling)
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4835471.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>
