Hash or Tree

[Wojtek]

Wojtek wrote :

BUT, I could place each key during the loading process into an ArrayList,
then when done create an array from it, then run through the array and set
the index value into the LangKey. Then use that index value to directly
access the array to get the value.

Ok, did the changes and ran 5 identical tests for each category. I hit
7 pages with 989 lokkups. And....

HashMap - average of 3,356 nano seconds
Array Lookup - average of 2,370 nano seconds

So there is a 33% reduction in lookup time.

Of course this is only a difference of 1 micro-second

And on a 2G laptop rather than our server class machines

 

[Wojtek]

Neil Coffey wrote :

I repeat, though: if you haven't profiled your code and found the hash
map gets to actually be significant, you may risk putting a lot of work
in changing your code for no tangible gain.

Hey, I gained a microsecond per call. After a few tens of years this
may amount to something...

Ok, ok, I was at loose ends for a day, I hate to be idle, and it was
kind of interesting.

And the SQL will completely swamp out any gains I might have made

 

[Wojtek]

Eric Sosman wrote :

Or else the test didn't run long enough relative to the
frequency of the underlying clock you timed it with.

Each test produced sort of consistent results, ranging from about 3,150
to 3,420 and 2,100 to 2,300.

And I completely resarted the environment between tests to reduce cache
impact. I actually ran each test 6 times, but threw away the first one
assuming that the OS would cache files.

So each of the first tests produced ~3K nanoseconds, while each of the
second tests produced ~2K nanoseconds

The actual number was not relavent to me, just the difference between
methods.

 

[Roger Lindsjö]

Neil Coffey wrote :

Hey, I gained a microsecond per call. After a few tens of years this may
amount to something...

Ok, ok, I was at loose ends for a day, I hate to be idle, and it was
kind of interesting.

Don't we all? The other day I had the "clever" idea of representing
words as a characters in a b*tree instead of just keeping them in a
list. Figured this would make lookup and storing more efficient. Well,
after implementing the tests showed that it was both slower and took
more space than the original solution. Oh well, at least it was a good
exersize.

 

[Daniel Pitts]

We found that people tended to mis-spell the keys, which meant the wrong
text, or no text was being displayed.

And that should have been caught in unit testing AND in QA testing.
Baring that, you could have a class (or several classes) that have
public static final String KEY_NAME;

So we created a class named LangKey which holds the key and the text
pattern. The text format method only accepts a LangKey plus an Object
array for parameters.

Sounds a bit like ResourceBundles.

It is not possible for keying mistakes with this method as the compiler
catches them.

As does the compiler catch MessageKeys.KEY_TYPO.Let your unit tests catch what the compiler misses, and you'll be
happier for using proven technology.