[Seaside] Re: Benchmark proposal

[Klaus D. Witzel]

Hi Ramon,

in the case you reported below method #do: is innocent, instead the sender  
of #valuesDo: has to be blamed for doing a sequential access to the  
elements of a dictionary (which may have and almost always has, to skip  
all the nil entries). Moreover, just the SoapHref members are filtered by  
SoapDecoder>>resolve and again, this might be a futile noop but  
aDictionary must check all its "raw" elements if its [the dictionary's]  
size > 0.

It may perhaps be possible to cache members of SoapHref in an array (or  
so) for speeding up SoapDecoder>>resolve drastically but this is only  
speculative because the relevant portions of SoapDecoder lack  
documentation 100%[tm].

/Klaus

On Thu, 18 Jan 2007 01:13:19 +0100, Ramon wrote:
>> > Just wanted to mention that there is IIRC a bit of work that can be
>> > done in the lower levels of Squeak web serving - at least
>> if you use
>> > KomHttpServer. I profiled and tweaked it quite a bit (2-3
>> years ago)
>> > for fun and managed to squeeze out a substantial improvement.
>
> For fun...  How about a look at this... For fun... I'm having some speed
> issues with SoapCore in conjunction with Seaside, i.e., using it with
> Seaside so it's kind of on topic....
>
> Using Soap against .Net.  It's my only access to my SqlServer database,  
> and
> recently I've noticed that a large part of my performance issues seem to
> stem from Soap Decoding.  I'd like to know what you think.  Here's a  
> Message
> tally on a result set that takes about 1.7 seconds to return from the
> service, but nearly a minute to decode 192 objects...
>
> - 54494 tallies, 54557 msec.
>
> **Tree**
> 100.0% {54557ms} WBBookingEngine>>soapCallBackDoor:sql:
>   100.0% {54557ms} SoapCall>>invokeAndReturn
>     97.7% {53302ms} SoapResponse>>returnValue
>       |97.7% {53302ms} SoapResponse>>buildAdditionalResults
>       |  97.7% {53302ms} SoapResponse>>extractDecodedValueFrom:
>       |    97.5% {53193ms} SoapDecoder>>decodeXmlElement:
>       |      96.2% {52484ms} SoapDecoder>>resolve
>       |        92.0% {50192ms} Dictionary>>valuesDo:
>       |          |92.0% {50192ms} Dictionary>>associationsDo:
>       |          |  92.0% {50192ms} Dictionary(Set)>>do:
>       |        2.7% {1473ms} SoapHref>>resolve
>     2.3% {1255ms} SoapCall>>invoke
>       2.3% {1255ms} SoapHttpConnector>>send:to:with:
> 
> **Leaves**
> 92.1% {50247ms} Dictionary(Set)>>do:
>
> **Memory**
> 	old			-1,547,728 bytes
> 	young		-72,492 bytes
> 	used		-1,620,220 bytes
> 	free		+1,420,712 bytes
>
> **GCs**
> 	full			1 totalling 229ms (0.0% uptime), avg 229.0ms
> 	incr		623 totalling 361ms (1.0% uptime), avg 1.0ms
> 	tenures		33 (avg 18 GCs/tenure)
> 	root table	0 overflows
>
> Which leaves me staring at #do: wondering where to proceed from here.  I
> emailed the author hoping maybe he'd have a better clue, but if anyone  
> likes
> tweaking code... Here's some code that needs tweaking.
>
> Ramon Leon
> http://onsmalltalk.com