On Thu, Mar 5, 2015 at 10:55 AM, Ben Coman <btc@openinworld.com> wrote:
On Thu, Mar 5, 2015 at 2:08 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan@stack.nl> a écrit :
On 04/03/15 14:19, phil@highoctane.be wrote:
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere.
There is no way an image starts that fast today.
There is the delay thing that slows things down.
Is this the code Eliot advised would not be needed when we've moved to the microsecond clock? Can you point me at the code? cheers -ben
Hi ben I've been following your Delay related work (sorry for the lack of feedback, still, I read it all). I will review where these things are and send you what I do find. t Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that. And that's on a i7 4770K clocked 3.85GHz with SSD drives. It takes less time to revive a VMWare VM :-( Phil
Norbert wrote:
To be sure if you want that you have to test it. You have always take
into account that a smaller file will have less I/O to read from disk.
+1
Ok.
Stephan