On Thu, Mar 5, 2015 at 10:55 AM, Ben Coman <[email protected]> wrote: > > > On Thu, Mar 5, 2015 at 2:08 PM, [email protected] <[email protected]> > wrote: >> >> >> Le 4 mars 2015 23:08, "Stephan Eggermont" <[email protected]> a écrit : >> > >> > On 04/03/15 14:19, [email protected] 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 >> > >> > >> > >> > >> > > >
