Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 33759 invoked from network); 24 Jan 2010 15:46:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Jan 2010 15:46:04 -0000 Received: (qmail 97215 invoked by uid 500); 24 Jan 2010 15:46:04 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 97115 invoked by uid 500); 24 Jan 2010 15:46:03 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 97107 invoked by uid 99); 24 Jan 2010 15:46:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Jan 2010 15:46:02 +0000 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=HTML_FONT_FACE_BAD,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of simone.tripodi@gmail.com designates 209.85.219.215 as permitted sender) Received: from [209.85.219.215] (HELO mail-ew0-f215.google.com) (209.85.219.215) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Jan 2010 15:45:54 +0000 Received: by ewy7 with SMTP id 7so491622ewy.10 for ; Sun, 24 Jan 2010 07:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=tTDtqGMJmgZusmpwZPyjQe88HN8oGn5fNs2Len3GY48=; b=Iei/RzJY55JF3OGbSYGZOTcQ8+8zva/8p0NPI5e8buigOf9yb65fvy7H/RcH7OeBXQ Z2CqV+gMKupdzNpPkhnP5jFYg8Dqa3INQ0798XWWx/G8B7XFTGqlTCRGmAZ6BLd18Mik BLm5sfXsrp2I6MNX1BY8Q9wiII9HKFYYu/9N8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=A3+2EtmUJfy9NXKeEFI2WbHFM1bHs1bEr7DDAtkGeEe/xK5B/pHGaIM8ReXQG77FoV BoRcwmWV2zjA7akAwkZ8+BFuD2gPg0a76hc44++s4F0j8qdw7g9NW3GYwiFzBo22cmko xAZhJQUeggNlrkE6h9ZD/IJ0dwjrvbOscuhp8= MIME-Version: 1.0 Received: by 10.213.97.28 with SMTP id j28mr2503518ebn.44.1264347934325; Sun, 24 Jan 2010 07:45:34 -0800 (PST) Date: Sun, 24 Jan 2010 16:45:34 +0100 Message-ID: <4173dc211001240745h22d279c3i70fe40834e7fd24@mail.gmail.com> Subject: [Cocoon 3] Optimizing resources creation on SAX pipeline components From: Simone Tripodi To: dev@cocoon.apache.org Content-Type: multipart/alternative; boundary=001636c5b63e7f7c2e047deaf179 X-Virus-Checked: Checked by ClamAV on apache.org --001636c5b63e7f7c2e047deaf179 Content-Type: text/plain; charset=UTF-8 Hi all guys, I'd like to improve a little the resources creation into C3 SAX pipelines components, saving consumed memory and components initialization time, reusing already created resources. I mean, instantiating the same kind of XSLTTransformer (or the SchemaProcessorTransformer) twice, in different parts of the application, with the same resource: class Service1 { XSLTTransformer xsltTransformer = new XSLTTransformer(this.getClass().getResource("myStyle.xsl")); ... } class Service2 { XSLTTransformer xsltTransformer = new XSLTTransformer(this.getClass().getResource("myStyle.xsl")); ... } causes the "myStyle.xsl" resource has to be load twice, consuming memory. As proposed time ago - also mentioned by Sylvain - I'd like to introduce an InMemoryLRU cache that stores and maintains already loaded resources. What do you think about it? It's a simple improvement I can realize quickly and that's not hard to integrate in the existing code, obviously any kind of help and suggestion is more than welcome! :) Best regards, Simo http://people.apache.org/~simonetripodi/ --001636c5b63e7f7c2e047deaf179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all guys,
I'd like t= o improve a little the resources creation into C3 SAX pipelines components,= saving consumed memory and components initialization time, reusing already= created resources.
I mean, instantiating the same kind of XSLTTransformer (or the SchemaP= rocessorTransformer) twice, in different parts of the application, with the= same resource:

class Service1 {

=C2=A0=C2=A0 =C2=A0XSLTTransformer=C2=A0xsltTransformer = =3D new=C2=A0XSLTTransformer(this.getClass().getResource("myStyle.xsl&= quot;));
=C2=A0=C2=A0 =C2=A0...
}

class Service2 {
=C2=A0=C2=A0 =C2=A0XSLTTransforme= r=C2=A0xsltTransformer =3D new=C2=A0XSLTTransformer(this.getClass().getReso= urce("myStyle.xsl"));
=C2=A0=C2=A0 =C2=A0...
}

causes the "myStyle.xsl" resource has to be load twice, co= nsuming memory. As proposed time ago - also mentioned by Sylvain - I'd = like to introduce an InMemoryLRU cache that stores and maintains already lo= aded resources.

What do you think about it? It's a simple im= provement I can realize quickly and that's not hard to integrate in the= existing code, obviously any kind of help and suggestion is more than welc= ome! :)
Best regards,
Simo
--001636c5b63e7f7c2e047deaf179--