<div dir="ltr">Hi Max,<div><br></div><div> pre-Spur to avoid GC one has to a) grow memory by enough to do all the processing you're going to do and b) change the shrinkage parameter so the Vm won't shrink the heap back down before the processing is complete. To do b) I suggest you modify setGCParameters. vm parameters 24 sets the shrinkage threshold; see vmParameterAt:put:: "24<span class="" style="white-space:pre"> </span>memory threshold above whichto shrink object memory (read-write)". growMemory. Hmmm, I had thoguht that there's a growMemoryBy: primitive in v3, but it appears there isn't. So simply allocate a ByteArray of the desired size and then GC to get rid of it. That should leave that much free space and then your load should proceed without needing to GC.<br></div><div><br></div><div>Anyway, it's worth a try.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 9, 2016 at 3:03 AM, Max Leske <span dir="ltr"><<a href="mailto:maxleske@gmail.com" target="_blank">maxleske@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
I have a rather annoying problem. I’m running a time critical piece of code that reads a big (~90MB) image segment from a file. I’ve optimized loading as far as possible and now GC takes far longer than the loading itself (see the MessageTally output below).<br>
I’m wondering if there’s any possibility to defer garbage collection during the load.<br>
<br>
For completeness, here’s the use case: the process is socket activated, which means that the first request coming in will start the process. When the image starts it will load the segment to restore the last state of the application and, once that’s done, serve the request. The critical time includes vm startup, image startup, starting the server in the image and loading the snapshot. With a big snapshot the loading time of the snapshot is the most significant contributor.<br>
<br>
Maybe I could preallocate the needed memory to prevent the garbage collector from running?<br>
<br>
I’d appreciate any ideas you have.<br>
<br>
<br>
Cheers,<br>
Max<br>
<br>
<br>
PS: This needs to run on a Squeak 4.0.3 VM (no JIT)<br>
<br>
<br>
<br>
<br>
Output from MessageTally:<br>
<br>
- 1624 tallies, 1624 msec.<br>
<br>
**Tree**<br>
--------------------------------<br>
Process: (40s) 592969728: nil<br>
--------------------------------<br>
4.4% {72ms} CBImageSegment class(NSImageSegment class)>>basicSnapshot:from:do:<br>
4.4% {72ms} CBImageSegment class(NSImageSegment class)>>installSegmentFrom:andDo:<br>
4.4% {72ms} CBImageSegment class(NSImageSegment class)>>readSegmentFrom:<br>
4.4% {72ms} NSSegmentStream>>readObject<br>
4.4% {72ms} SmartRefStream>>nextAndClose<br>
4.4% {72ms} SmartRefStream>>next<br>
4.3% {70ms} SmartRefStream(ReferenceStream)>>next<br>
4.3% {70ms} SmartRefStream(DataStream)>>next<br>
3.2% {52ms} NSImageSegment(ImageSegment)>>comeFullyUpOnReload:<br>
3.2% {52ms} NSImageSegment>>restoreEndiannessAndRehash<br>
**Leaves**<br>
3.2% {52ms} NSImageSegment>>restoreEndiannessAndRehash<br>
<br>
**Memory**<br>
old +92,704,656 bytes<br>
young -8,008,252 bytes<br>
used +84,696,404 bytes<br>
free +1,287,768 bytes<br>
<br>
**GCs**<br>
full 2 totalling 954ms (59.0% uptime), avg 477.0ms<br>
incr 5 totalling 165ms (10.0% uptime), avg 33.0ms<br>
tenures 1 (avg 5 GCs/tenure)<br>
root table 0 overflows</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div>