[Seaside] Looping through all children as a performance issue

[Lukas Renggli]

> 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