Jodatime's LocalDateTime is slow when used the first time

Question

I'm currently testing out some webapp technologies in a java project and was wondering why the pages sometimes load fast and sometimes take almost 5s to load.

I finally found out that it is this line

LocalDateTime now = new LocalDateTime();

When it's called the first time, it takes forever to get the current time. When called after that, even somewhere completely different, it's pretty fast however.

I'm currently using

    <dependency>
        <groupId>joda-time</groupId>
        <artifactId>joda-time</artifactId>
        <version>1.6.2</version>
    </dependency>

Has anyone had any similar experience? Really stuck here.. I could use LocalDateTime some time early in my application to fasten up subsequent calls - but this seems pretty dull tho.

EDIT

I misuse Spring for that now:

@Service
public class JodaTimeLoader {

  public JodaTimeLoader() {
    LocalDateTime loadMe = new LocalDateTime();
  }

}

score 12 · Answer 1 · answered Jun 15 '11 at 07:12

12

Joda-Time is designed for long running enterprise systems where a one-off up front load time is irrelevant compared to the faster performance during the rest of the application.

answered Jun 15 '11 at 07:12

JodaStephen

60,927
15
95
117

score 9 · Accepted Answer · answered Jun 08 '11 at 15:22

9

The first time you do that, Joda Time loads a number of static resources (e.g., its chronology descriptors) which is the cost that you're seeing. This is a one-off cost; you pay it once per process. Load it early during startup if it really bothers you, perhaps like this:

static {
    // Build the local caches inside Joda Time immediately instead of lazily
    new LocalDateTime();
}

answered Jun 08 '11 at 15:22

Donal Fellows

133,037
18
149
215

Ok - thanks for your detailed answer. But I think I'll not use jodatime anymore - can't really see any advantages at the moment. Do you load their resources eagerly in your productive environments? – chzbrgla Jun 08 '11 at 15:26
doing that, preloading resources, in static initializer is a very bad idea. what you want to do is delegating the load to another thread and pray no one is trying to use it. either way taking 0.1sec to load is a very bad design. – bestsss Jun 08 '11 at 15:33
2

@bestsss: You seriously think that just putting it in another thread is better? Explicit instantiation during application setup, I can see that being a reasonable thing to do. However, adding extra threads just to knock maybe 100ms off a one-time cost is just asking for trouble, especially at a point when you've already got pretty much peak resource contention. – Donal Fellows Jun 08 '11 at 22:02
no, starting the thread is done only after the initial start-up but before joda is needed. In case there are enough free cores, the 2nd thread can help reaching the necessary count for the JVM compiler to kick in. And in case chronology descriptors are quite a bit they can be loaded one by one I suppose. – bestsss Jun 09 '11 at 23:00

score 6 · Answer 3 · answered Jun 08 '11 at 14:59

6

It takes about 77 ms on my system. That is quite long for a class.

Perhaps you just have to call it once on startup to make sure its already loaded.

If you want the current time quickly you can use System.currentTimeMillis(); which takes 0.0018 ms the first time I call it.

answered Jun 08 '11 at 14:59

Peter Lawrey

525,659
79
751
1,130

Ya.. but I really don't like this 'load it at the beginning to make it load faster later'-approach :p But thanks for the milli second method's benchmark.. maybe I'll just resort to that - no more Jodatime then ... :D – chzbrgla Jun 08 '11 at 15:04

Jodatime's LocalDateTime is slow when used the first time

3 Answers3

Linked