> I was wondering if it would be possible to internalize string > keys (calling intern() method) for both primary and foreign > keys (as defined in the Keys class) when these are selected > from the database during the record construction.
While certainly possible, it would not help. On the performance side, comparing unequal strings (the normal case) cannot declare inequality if == does not hold because one of the strings might be uninterned. You'll have an advantages only when comparing strings that turn out to be equal. This means that you'll probably have to halve the effect. Also, internalized Strings objects survive class unloading AFAIK. This means you get a memory leak in containers that created and garbage collect class loaders routinely. The leak is small (just those strings that are never used again) but since we're discussing marginal effects here, it's a factor. The effect is near-zero when dealing with hash table keys - the JVM needs to access the string bytes to construct the hash key after all. The right way to enable equality comparisons would be to define an enum for each domain. (The downside would be a proliferation of enum classes, so it's probably not worth it either.) In general, micro-optimizations like this should not be done unless you're sure it has any noticeable effect. IOW did you benchmark that string comparison actually has a noticeable effect on Jooq's performance? (Personally, I doubt that, but I wouldn't be sure unless actually benchmarking it.) I'd run the code inside a profiler and check how much time your application is actually spending in String.isEqual(). Then, find out how much of that is actually triggered from Jooq. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
