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).
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.
