[aida] Reclaiming Memory in Aidaweb

Herbert König herbertkoenig at gmx.net
Tue Oct 26 21:40:29 CEST 2010


Hi Janko,

long post, I did some coding inbetween :-))
JM> Do you feel that Aida is slow somewhere and it is a time to start
JM> optimizing it?

right now I'm simply not qualified to make such observations. That's
why I plan to benchmark my app + Aida. In my old 3.8 image after
spending those 4 seconds to generate the data I found browsing the data
quick and responsive.

The one place I found slow I can attribute to how my app prepares the
data for Aida to display. This could be simply improved by some caching.

If you remember the "onClickDoAndUpdateMany" discussion with Alex
Baran, this also created something slow in Aida.

Imagine a WebGrid, 4 columns 10 rows. Each of these 40 elements needs
to AjaxUpdate 5 Elements on the page, including the Grid. So each of these
elements needs 5 AjaxUpdaters. Creating 240 times the more or less
identical javascript necessary for an AjaxUpdater and transferring all
these to the browser was slow. This happened on every click into the
table.

I changed that to have one single function like: (just count the
bytes)
<script type="text/javascript">function updProf(elementId){new Ajax.Updater('id4', '/ellingweb.html', {method: 'post', postBody: 'view=profile&&ajaxRequest&ajaxGetElementId=id4&aidaCtx=10786&blockElementId=' + elementId + '&blockName=onClickBlock', onComplete: function() {new Ajax.Updater('id16', '/ellingweb.html', {method: 'post', postBody: 'view=profile&&ajaxRequest&ajaxGetElementId=id16&aidaCtx=10786', onComplete: function() {new Ajax.Updater('id7', '/ellingweb.html', {method: 'post', postBody: 'view=profile&&ajaxRequest&ajaxGetElementId=id7&aidaCtx=10786', onComplete: function() { inCall = false; ; }, evalScripts: true});; }, evalScripts: true});; }, evalScripts: true}); };</script>

and an Element of the WebGrid now only renders as:
<td align="right"><span id="id28" onClick="updProf('id28');"; ">2.500</span></td>

whereas before it had the whole script in every onClick function.

This was a good speedup in response time to a single click of a single
user. I can share this on request otherwise I will propose it as
a change when it has left the status of a raw hack. (not this year I
assume)


JM> I'm specially wary about the "climbing the stack" methods, which find a
JM> reference to some object through thisContext and then recursively up in
JM> the stack. Like Object>>firstAppFromStack. Those methods are used more
JM> and more frequenty, because are so handy and they simplify the code a lot.

Do they show up in a message tally as a bottleneck? If you drill down
firstAppFromStack until Behaviour>>isKindOf: you'll find several (not
nested) loops. This looks slow but I learned to not trust my own
assessment "this looks slow".

For benchmarking I believe I have to change the place in swazoo where
the HTTPRequest objects are generated to collect all these.

Hey that's easy I just coded up a class RequestLog which has a
ClassVar to collect the request and one method to to add a request to
the log. Then I added:
RequestLog addRequest: request to HTTPConnection>readRequestFor:
after the request gets its timestamp set.

Then I'll log a single Session of me using my app (maybe tomorrow)

and then:

and replay this log from say 10 images (or one image running 10
HTTPclients) simultaneously and watch what happens to the response
times of the server if I increase the number of clients.

Do you have / know of such a tool? Something that gets a bunch of
HTTPRequests fires them at a server and retrieves the replies?

Or do you think the whole idea is bad?

If I have that, I could confidently tell you in what situations I want
Aida to be faster.

Cheers,

Herbert                            mailto:herbertkoenig at gmx.net



More information about the Aida mailing list