2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianop...@gmail.com>:
> Then the only thing I can think of is a vm primitive that is implemented > differently in linux/mac than windows vm... > Yes, the vm primitives, like I already told some messages above. FilePrimitives ARE slow on windows. We may get better performance, if we disable windows file cache/buffering and use slightly different ways to do the CreateFile and WriteFile calls, and do the buffering on our own, but this is not easy. Luckily (?), this may be alread work if we use the std file api (?) A small dirty test: store bench latest vm -> '22.098 per second' modified vm -> '31,027 per second' (in the modified vm I replaced all file operation from sqWin32FilePrims.c with the code from sqFilePluginBasicPrims.c) The result may seem strange, because both implementation will actually use win32s CreateFile/WriteFile methods, but maybe the second one uses better caching/buffering. nicolai > > On Tue, Jun 30, 2015 at 7:07 PM, Jan Blizničenko <blizn...@fit.cvut.cz> > wrote: > >> I'm gonna try to reply to all of you and try your ideas >> >> >> Stephan Eggermont wrote >> > On 30-06-15 14:37, Jan Blizničenko wrote: >> >> Unfortunately no - all benchmarks I made with antivirus disabled. >> > >> > Including the Microsoft stuff itself? (Security Essentials/Windows >> > Defender) Does your desktop have a drive > 2TB? >> >> Yes, all such things I have disabled / removed. >> >> >> >> Mariano Martinez Peck wrote >> > Can you think of any other window process that could be detecting >> changes >> > all the time in .changes and therefore have an impact in the >> performance? >> > Do you have such pharo image in dropbox or similar service? >> >> I don't think so. I tried even running Windows in diagnostic startup (safe >> mode / running with only core processes and services) and it had no >> effect. >> >> >> >> Mariano Martinez Peck wrote >> > I would check the processes running and CPU of Windows while loading the >> > code... >> >> I was looking at it some time ago and it didn't seem like processor is too >> much busy, but as I think about it, it is suspiciously almost not busy at >> all ... ~1 % of processor usage. On laptop it fluctuates between 5 and 10 >> %. >> I'm talking about usage when benchmarking the "store" code. >> >> >> >> philippeback wrote >> > Silly question: do you have a couple of Nautilus windows open? >> > >> > Loading stuff generates annoucements and Nautilus updates are killing >> > performance. >> >> No, only open thing is Playground from which I run the benchmarking codes. >> >> >> >> Sven Van Caekenberghe-2 wrote >> >> On 30 Jun 2015, at 18:36, Peter Uhnák < >> >> > i.uhnak@ >> >> > > wrote: >> >> >> >> I think we've safely established that the bottleneck is disk >> operations. >> > >> > Let's take it one level down then, >> > >> > [ 'foo.txt' asFileReference in: [ :file | >> > file writeStreamDo: [ :out | >> > 3 timesRepeat: [ out << String loremIpsum ] ]. >> > file ensureDelete ] ] bench >> > >> > => "'512.595 per second'" >> > >> > We could experiment with variants, calling #flush, writing by character, >> > adding buffering, etc, but this is a start. At least this takes the >> source >> > code stuff out of the equations. >> >> "654.738 per second" on desktop >> "1,271 per second" on laptop >> >> >> Thank you all for ideas. >> Jan >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4835019.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
