forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: machine spec for forrest run
Date Thu, 03 Nov 2005 12:25:55 GMT
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 
> 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:

> 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 ;-)


View raw message