Looping through all children as a performance issue

Hello all,

Our small team has been working over most of 2007 on writing a portal website based on Seaside (currently still 2.7) in VW5, which expects several hundred to, a bit later, even several thousand simultaneous users, of course not on one server hardware. I will soon introduce it here.

I have only joined in a few months ago and I am therefore still in the process of understanding the internals of Seaside - and there are various aspects where I am having my problems with despite the overall excellent idea to enhance Smalltalk to a web server.

For this I do want to sincerely thank the initiators.

Performance is currently my main concern, especially the permanent looping through all children. Our portal consists of currently about 25 nested tab views and that will grow up to over 100 till the end of this year.

I find the concept of looping through all children for every request quite awkward and it seems to me that this is wasting a lot of time. Also it requires that all needed controller classes be initialized during start-up although most will never be needed for a session.

For me this is like on a hotel reception where a visitor (request) is asking in which room a specific person (callback ID) lives. In a hotel the concierge would look the name up on a list and tell the visitor the room number and how to get there straight away.

Seaside is more sportive: It runs through all floors, knocks on every door and checks all the names of every person in every room – for every request. Pardon, but I find this a very strange behaviour that nobody would practice.

My questions:

- Are there any plans to create a central dictionary, which can be interrogated by a request and which avoids endless looping through the entire tree?

- Are there any serious reasons why this is not done? Or cannot be done?
(Maybe I completely misunderstood something?)

If both questions are answered with No then we will most likely develop such an enhancement (after moving to 2.8), because I doubt - from my current limited state of knowledge - that this current procedure makes sense and that we could and would want to live with it.

Best regards
Frank

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Performance is currently my main concern,
> especially the permanent looping through all
> children. Our portal consists of currently
> about 25 nested tab views and that will grow
> up to over 100 till the end of this year.

Normally you only return the components from #children that are
actually rendered. Seaside will only iterate over those, see for
example WASimpleNavigation for a nice implementation of a tab-panel.

> I find the concept of looping through all children
> for every request quite awkward and it seems
> to me that this is wasting a lot of time.

This is useful for various things, because components might want to ...

1. parse the initial request (#initialRequest:)
2. change the current URL (#updateUrl:)
3. register objects for backtracking (#updateStates:)
4. render something to the XHTML head (#updateRoot:)
5. render something to the XHTML body (#renderContentOn:)
6. process callbacks (#processCallbackStream:)

Indeed step 2-3 could be combined, but for the rest it makes perfectly
sense to keep them separate. Even most complex Seaside applications I
have seen up to know don't display more than 20 components at once and
in this case I could never see a measurable performance issue.

> Seaside is more sportive: It runs through all floors, knocks
> on every door and checks all the names of every person in
> every room   for every request. Pardon, but I find this a very
> strange behaviour that nobody would practice.

Seaside components cannot be compared with a flat list of rooms.
Seaside components are nested in a tree. Components closer to the root
can influence processing its children. When you call a component it
delegates all processing to a new component.

> - Are there any plans to create a central dictionary,
> which can be interrogated by a request and which
> avoids endless looping through the entire tree?

We have done a lot of benchmarking in Seaside 2.7. In Seaside 2.8 we
optimized major bottlenecks and got the request processing to be run
about twice as fast compared to earlier versions. None of our
optimizations were related to the iteration process over the children,
simply because this never showed up in the benchmarks.

> If both questions are answered with No then we will
> most likely develop such an enhancement (after
> moving to 2.8), because I doubt - from my current
> limited state of knowledge - that this current procedure
> makes sense and that we could and would want
> to live with it.

I suspect that you return too many children in your application. It
usually doesn't make sense to return children that are not being
rendered from #children.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Lukas Renggli" <[hidden email]> wrote in message

> Normally you only return the components from #children that are
> actually rendered. Seaside will only iterate over those, see for
> example WASimpleNavigation for a nice implementation of a tab-panel.

SUNavigation (and subclasses SUTabPanel, SUAccordian) currently seems to
include all its elements in #children. Should it limit it to just the
#selected tab or #visible accordion?

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Normally you only return the components from #children that are
> > actually rendered. Seaside will only iterate over those, see for
> > example WASimpleNavigation for a nice implementation of a tab-panel.
>
> SUNavigation (and subclasses SUTabPanel, SUAccordian) currently seems to
> include all its elements in #children. Should it limit it to just the
> #selected tab or #visible accordion?

This is exactly why I wrote:

        *Normally* you only return the components
        from #children that are actually rendered.

In the case you add or remove components trough AJAX updates (like
this is done in SUTabPanel and SUAccordion) you need to be extremely
careful. 1,2 and 4 do never happen for such dynamically added
components, and usually this is no big deal. In the end, it all boils
down to avoid ending up with an error saying "Children not found while
processing callbacks". In any doubt (or with enough laziness) it never
hurts to answer too many children, unless you have hundreds of them.

Since Seaside does backtrack state for AJAX updates much more
precisely now, as compared to the time when SUTabPanel and SUAccordion
were written, it would probably make sense to revise this design
decision. Maybe you want to file a bug report?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Lukas Renggli" <[hidden email]> wrote in message
> In the case you add or remove components trough AJAX updates (like
> this is done in SUTabPanel and SUAccordion) you need to be extremely
> careful...

Thanks for the careful explanation.

> Maybe you want to file a bug report?

Sure, though it was more for my understanding than a "bug".

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside