Mailing-List: contact batik-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xml.apache.org
Message-ID: <412F033C.7060809@cs.rutgers.edu>
Date: Fri, 27 Aug 2004 11:47:40 +0200
From: George Armhold <armhold@cs.rutgers.edu>
User-Agent: Mozilla Thunderbird 0.6 (X11/20040519)
MIME-Version: 1.0
To: batik-dev@xml.apache.org
Subject: Re: Performance of Batik.dom.svg.SVGOMDocument.getById()
References: 
 <131A71243F0BF246A6FEAC95414AC11D556CD7@cceexc13.americas.cpqcorp.net>
In-Reply-To: 
 <131A71243F0BF246A6FEAC95414AC11D556CD7@cceexc13.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sieker, Fritz wrote:

 > I used Jprobe and found that the biggest time sink was in
 > Batik.dom.svg.SVGOMDocument.getById().
 >
 > [ ... ]
 >
 > As an experiment, I replaced the scan of "protected static Element
 > getById(String id, Node node)" by a hash table.
 >
 > [ ... ]
 >
 > The results were dramatic, with the > 20 minute load dropping to
 > just a few seconds.

I ran into the same problem, came up with a similar solution, and got
the same impressive speedup.  Except I implemented my HashMap cache
outside of Batik, in my own application space.  Not to say that my
solution was any better/worse, just "me too".  Would be nice to see
this optimization added to Batik in the proper way.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org