Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <436A01D3.3020903@apache.org>
Date: Thu, 03 Nov 2005 12:25:55 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: machine spec for forrest run
References: <20051031100414.GA12278@igg.indexgeo.com.au>
	 <1130782394.4077.58.camel@k2.flat5>
  <1130924581.8271.13.camel@localhost>	 <1130973649.3898.18.camel@k2.flat5>
  <4369DF94.1050804@apache.org> <1131013722.8195.23.camel@localhost>
In-Reply-To: <1131013722.8195.23.camel@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Thorsten Scherler wrote:
> El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribi=C3=B3:
>=20
>>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=
=20
>>that there are lots of performance issues with views 2.=20
>=20
>=20
> 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 no=
t
> use xinclude at all (beside the default usage from main pipes of forres=
t
> core).

OK, maybe I spoke too soon. But I do think there is much happening in=20
XSL that need not happen in a memory exhaustive approach. This is not a=20
criticism of your work, merely an observation of how it can be improved=20
with respect to performance.

>>The tentative=20
>>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=20
>>example, need not be done with processor and memory intensive XSL=20
>>transforms.
>=20
>=20
> 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=20
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.
>=20
>=20
> That is not true! Like stated above I ripped out the xinclude stuff tha=
t
> was pointed out to be the worst part for performance.

Sorry, performance is being addressed, please help ;-)

Ross