On Thu, Jul 2, 2015 at 11:39 PM, Jan BlizniÄenko <bliznjan@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-p... http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-a... 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-tp4834668p48... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.