30
Trust Your API (Railo Caching Silliness)
3 Comments · Posted by Elliott in ColdFusion, Programming, Railo
One of the biggest problems rampant amongst developers is ignoring the standard library and writing your own solution to the same problem because we think it’s faster/smarter/better. I know I’m certainly guilty of this thinking too. Unfortunately this is pretty much always a mistake. I recently stressed this issue quite a lot in my Designing Scalable and Creative Algorithms presentation showing how using built in CF features instead of writing your own algorithm (even if theoretically more efficient) often provides significant performance improvements.
A good example I’ve found of this problem is the Railo railo.runtime.op.Constants class in the Railo runtime source. This class contains a cache for java.lang.Integer instances and methods for getting them from primitive values. It also contains named constants for the values up to 10 and creates the values manually up to 99 and puts them in an array. Another method is provided that converts boolean primitive values to java.lang.Boolean instances.
The sentiment behind this class makes sense. It reduces the number of Integer instances that need to be created and reduces the amount of garbage being generated by the program.
The problem here is that both of these methods implement a feature that already exists in the Java API. Moreover since the method is part of the API it’ll likely get compiled to native code much faster.
Had the Railo developers trusted the API (and read the documentation) they would have used Integer.valueOf(int) and Boolean.valueOf(boolean). Both of these standard API methods use a cache, and the Integer cache provided in the standard library caches values from -128 to 127 (as required by the Java Language Specification) providing a much more expansive cache than the 0 to 99 values the Railo developers implemented.
So back to what I said in my presentation: Trust the API: It is Faster!
Note:
It should be noted that Railo supports Java 1.4+ and the cache is only present in 1.5+ so using their own cache in Railo does make some sense, but their use of new Integer() instead of Integer.valueOf() and only caching values of 0-99 means you never get the benefit from Java 1.5+
Second Note:
Apparently this has been fixed in bleeding edge Railo, though the source bundle and the SVN repo haven’t been updated. For anyone else who wondered, they keep that source on Git Hub.
No tags
Sean Corfield · August 30, 2010 at 11:49 am
I just looked at the comment exchange on that ticket – are you going to update this blog post to reflect that?
Offner Michael (CTO Railo Technologies) · August 30, 2010 at 12:05 pm
First of all your right in this case and because that we have already changed this in our code.
This class was written when we still have supported java 1.4 and because java 1.4 has not supported this feature (java.lang.Integer.valueOf(int):Integer) we had to do on our own, we have selected the range from 0 to 100, because most number used inside the most popular application are in this range, before we have selected this range we have add a logger to the method Constants.Integer and then we have logged the numbers used while running different apps. in theory the jre implementation is better but in the real world it makes no difference and the railo impl use less memory.
the usage of objects from type Integer is very rare in Railo, because all numbers defined in the cfml code are handled as Double Object, Integer are mostly used for invoking for 3party libs.
“Moreover since the method is part of the API it’ll likely get compiled to native code much faster.”
classes like java.lang.Integer are in a regular jar archive, there is no difference between them and classes written by me or you, they are not faster, they work exact the same way. most (or even all today) JRE have a runtime compiler that translate the os indepedned bytecode to machine code at runtime.
“Trust the API: It is Faster!”
Newer trust a api that you not have written by yourself ;-)
the JRE library is very good but also the people at Sun are not perfect, new ideas only come in the field when there is a need for, not in the labs.
for example railo has it’s own floating number parser, simply because it is faster than the jre parser in 99% (or more) of all the cases used in railo. railo has it’s own color definition parser, simply because it is more flexible than the jre color parser. we are on the way from switiching from JRE Date Handling to Joda (see classes railo.commons.date.JREDateTimeUtil, railo.commons.date.JodaDateTimeUtil) simply because joda is faster/better.
and all this are only things i have in mind at the moment.
but like sun we are more than open for suggestions to improve our current code base, but defintily no api or app is perfect and need no improvement.
/micha
p.s. sorry my bad english need improvment as well ;-)
Author comment by Elliott · August 30, 2010 at 4:08 pm
@Sean
I have added a comment that there’s a fix in your bleeding edge code.