Thorsten Scherler wrote:
El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
Kevin wrote:
Does anyone have a performance problem using forrest run.
My test is on the main index page of seed-v2.
I'm not using views 2, so cannot comment directly. However, it is known
that there are lots of performance issues with views 2.
Why? If you have said v1 than you get a +1 from me because of the
extensive usage of xinclude which is not cacheable in v1. In v2 I do not
use xinclude at all (beside the default usage from main pipes of forrest
core).
OK, maybe I spoke too soon. But I do think there is much happening in
XSL that need not happen in a memory exhaustive approach. This is not a
criticism of your work, merely an observation of how it can be improved
with respect to performance.
The tentative
plan is to move much of the heavy XSL processing into Java components.
Most of the stuff that is done to bring the contracts together, for
example, need not be done with processor and memory intensive XSL
transforms.
Actually I debugged it a bit and what I see is that the locationmap
lookups are taking ages. Since v2 is totally based on the lm that may
have introduced some new performance issues.
Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
Sorry for not being faster in providing a transformer for overcome the
xsl aggregation but I am ATM a wee bit handicapped without an internet
connection and moving all v2 stuff to their final locations.
Come on Thorsten, you know there is no need to apologise. We don't
expect *you* to do it, I only raise it here so that everyone is aware of
things that need to be done and therefore how they can contribute.
In other words, performance has not been addressed yet.
That is not true! Like stated above I ripped out the xinclude stuff that
was pointed out to be the worst part for performance.
Sorry, performance is being addressed, please help ;-)
Ross
