On 01.01.2011 14:39, Levente Uzonyi wrote:
> On Sat, 1 Jan 2011, Philippe Marschall wrote:
>
>> Hi
>>
>> I've been doing some performance work lately in Seaside. Long story
>> short Seaside (and I guess AIDA too) spends of if it's rendering time in
>> WriteStream (#nextPutAll:, #nextPut:).
>>
>> The way WriteStream >> #pastEndPut: behaves is not really ideal for
>> Seaside. It grows the underlying collection by just enough to
>> accommodate the argument collection (or 20 which ever is bigger). Now
>
> No it doesn't. The code in #pastEndPut: is
>
> collection := collection grownBy: ((collection size max: 20) min: 1000000).
>
> so the argument of #grownBy: is at least 20, at most 1000000 and it's
> size of the internal buffer (collection) if it's between 20 and 1000000.
> So in most practical cases it's the value of [collection size].
> #grownBy: allocates a new collection that has the size of the
> collection's size + the argument, which is 2 * self size in the most
> common case. So the size grows exponentially till it reaches 1000000 and
> then linearly (with a relatively high constant 1000000). This guarantees
> that the cost of #nextPut: is constant in most cases.
You're right, I misread the code, that's the behaviour for #nextPut:.
However #nextPutAll: does:
newEnd := position + aCollection size.
newEnd > writeLimit ifTrue:
[self growTo: newEnd + 10].
and #growTo: does then:
newSize := anInteger + (oldSize // 4 max: 20).
grownCollection := collection class new: newSize.
aCollection is the argument collection, not the underlying collection.
So that's the required size puls ten plus the max of a fourth of the
current size and 20.
>> image the following not very unlikely scenario. You start with a 4k
>> buffer and put on average a 10 element collection (remember all those
>> tags are put individually) until you have a 16k response. You allocate
>> more than a thousand intermediary collections to get there.
>
> So just 3: one for 4k (the initial), one for 8k and one for 16k.
Yes.
>> What would be better suited for Seaside is doubling the required size.
>
> That's exactly what's happening in most cases.
In the #nextPut: case, not in the #nextPutAll: case.
>> In the worst case that would mean wasting 50% of memory but it would
>> make the overhead of creating intermediary collections logarithmic. In
>
> The overhead is constant (amortized) in most cases.
>
>> the given example that would take us only three allocations to get there.
>> Now I do realize there are other applications for Pharo where this
>> strategy is not ideal and this is not a killer for us. I just wanted to
>> shed some light and this and ask whether other projects are in a similar
>> situation.
>>
>> To get a feel how allocation limited Seaside is: avoiding one allocation
>> of a 16k ByteArray per request can make a difference in throughput
>> between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP
>> Components"). If anybody knows a way to make allocation of large young
>> space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd
>> like to hear it.
>
> IIRC CogVM's GC is different from SqueakVM's GC in the sense that it is
> activated when a predefined amount of data is allocated, not when the
> number of allocations since the last GC reaches a predefined limit. So
> you have to tune the GC differently on Cog and non-Cog VMs.
Do you know where I can find more information about this?
Cheers
Philippe
