writeImageFile() without snapshot()?
John M McIntosh
johnmci at smalltalkconsulting.com
Sat Oct 8 00:11:11 UTC 2005
Avi, so does the write to disk actually take 12 seconds? You could
look at
writeImageFileIO or up in writeImageFile and stick a fork there and
have the child do the I/O.
A bit further away from the OO space at this point so it's clearer
what you are doing perhaps.
On 7-Oct-05, at 4:34 PM, Avi Bryant wrote:
>
> On Oct 7, 2005, at 4:09 PM, John M McIntosh wrote:
>
>
>> Of course if you have a spare GB or two, you could do the fullGC
>> ask for a block of memory, copy start of memory to end of memory
>> there, then write that out
>> at your leisure, that forgoes the need for fork and the like.
>> Assumes of course you can ask and get 500MB at no cost.
>> Surely the write happens quite quickly on modern high-speed disk i/
>> o machines tho?
>> Seems to me if you're wanting to minimize downtime you fork and do
>> a snapshot, that as noticed takes upwards of image size to do.
>> Otherwise as you say full GC, fork for the write, but does that
>> save anything?
>>
>
> The scenario is that you have a server packed with large images
> that you want saving to disk periodically. So mostly what I'm
> trying to optimize is memory usage, but without unreasonable delay
> by the standards of web applications. The two options that take
> more or less constant memory seem to be a regular snapshot, or GC-
> >fork->snapshot. For a largish image (100-200MB), a GC takes maybe
> 2s (acceptable, if annoying) whereas a snapshot takes maybe 15s
> (pretty much unacceptable). So the forking seems like the right
> choice. Though if we could get rid of the GC altogether that would
> be great...
>
> Avi
>
>
>
>
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Squeak-dev
mailing list
|