Then the only thing I can think of is a vm primitive that is implemented differently in linux/mac than windows vm...

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.




--
Mariano
http://marianopeck.wordpress.com