This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: java.util.Date.toString() really slow?
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Adam Megacz <gcj at lists dot megacz dot com>, java at gcc dot gnu dot org
- Date: Mon, 3 Jun 2002 11:27:03 -0400 (EDT)
- Subject: Re: java.util.Date.toString() really slow?
On 3 Jun 2002, Tom Tromey wrote:
> >>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:
>
> Adam> The following code takes 1:35 using 3.1-branch and 0:02 with
> Adam> HotSpot. Any ideas why?
>
> I doubt anybody has ever looked at the performance of this method.
> I think I've worked on it before for correctness, but I know I've
> never looked at making it faster.
I missed the original post so I haven't seen Adam's example, but I'll
hazard a guess based on my observations.
Date.toString() relies on the Calendar code, which in turn loads a
resource bundle. ResourceBundle looks first for a localized bundle, e.g.
Calendar_en_US. Since this doesn't exist it falls back to Calendar_en.
Moreover java.util.ResourceBundle doesn't cache failures, so it tends to
search the library path each time a Calendar is instantiated.
Running truss on Solaris I saw thousands of failed opens per second, with
names like lib-gnu.so, lib-gnu-java.so, etc. My first attempt to fix
ResourceBundle failed, so I worked around it by adding
gnu/java/locale/Calendar_en_US.java to my build.
Jeff