2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianopeck@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 <bliznjan@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 &lt;

> i.uhnak@

> &gt; 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.




--