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!

Railo Bug Ticket 934

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.

So I’m happy to announce the Unofficial Adobe CFBuilder Bug Database Mirror!

Enjoy.

This performance hit is not some small amount. Creating an empty component that’s imported will cost anywhere from 8-16ms without the cache. That makes CF7 createObject() performance look fast!

Definitely go bug Adobe about this because this kind of performance hit makes import useless. Until it’s fixed leaving component cache off will quickly cripple any new CF9 app and makes development a lot slower too.

Here’s the bug ticket: Bug 83864

Note:

The reason you might disable Component Cache is because the feature is quite buggy and has a tendency to resolve components to the wrong locations between applications that use application specific mappings. Meaning that most shared hosts will probably need to leave this off. That means that object creation performance is going to be terrible on shared hosts if you use import and don’t qualify your components, and qualifying them and still using import rather defeats the purpose.

It was so great to meet everyone new, and see everyone old. Hope to see you at the next conference, whatever that may be!

• Designing Scalable and Creative Algorithms
• I bet you didn’t know you could do that with ColdFusion

Unfortunately they also created it in Flex so it’s a super huge pain to use. For instance lots of the text isn’t selectable like comments and votes. Undo (Apple+Z) doesn’t work in any of the text boxes like the search box and even worse the drop down for Bug Areas has (no exaggeration) over 100 items in it with no scrollbar and no keyboard support!

We pushed Adobe on the prerelease to create an HTML UI that wasn’t so lame, but that never happened. :(

Well, rather than just complain about this I went and created my own.

So I officially announce the Unofficial Adobe ColdFusion Bug Database Mirror.

Enjoy!

The code samples have a Prototype.cfc and some examples that use complete objects as the prototype like with JS.

user = createObject("component","User").init();
admin = createObject("component","Admin").init();
admin.setPrototype(user);

me = admin.new();
me.setName("Elliott Sprehn");

// Somewhere off in plugin land...
function toXML() {
	return "
		
			#this.getName()#
		";
}
user.toXML = toXML;

// In the application's code
writeOutput( me.toXML() );
/*
	
		Elliott Sprehn
	
*/

One reason I really like this is that it lets you arbitrarily extend the model in plugins without impacting object creation performance.

There’s a tendency to go crazy with the Factory pattern and then broadcast lots of events (transfer takes this approach with actionAfterNewTransferEvent and friends). Unfortunately it makes object creation slower and slower since each create has to notify more and more listeners.

The Eclipse IDE ran into this problem and called it the “event storm” where a single mouse click might fire thousands of events and make the whole IDE seem slow.

Using prototypal inheritance we can pre-compute the entire prototype chain and all the complex object state so that each object create only needs one extra setPrototype().

Thinking outside the traditional class based object approach can solve many future problems and make your life easier. Whether it be by using function pointers creatively or something even less conventional like prototypal inheritance.

<cfset this.mappings["/myapplication"] = expandPath("../")>

See the bug there? ExpandPath() is relative to the requested template. This application had previously had all requests routed through /public/index.cfm so the mapping worked fine.

However, recently we had added some new web services like /public/services/ScheduleService.cfc and now whenever an Ajax request went through the CF mapping would change from pointing to / to /public causing all other concurrent requests to fail with confusing missing file errors.

I fixed this by making sure the path was no longer relative.

<cfset this.mappings["/myapplication"] =
   getDirectoryFromPath(getCurrentTemplatePath())>

So the moral of the story is to NEVER use expandPath() to create a mapping that’s relative to the webroot.

<cffunction name="test" myAttribute="1">
  <--- How can we get the myAttribute value? --->
</cffunction>

The first obvious attempt at this is to use getMetaData(test).myAttribute, and that works fine until you pass the function as a pointer and then it’s not called test anymore. Instead we need a different way to get the current function.

I had looked into this for implementing closures some time ago, and even talked about this at BFusion 2008. My original workaround was to create an API around the function pointer. For example executeFunction(func) that passes the function pointer in as an argument. Unfotunately, this also means you can’t just pass this function around transparently to anything that expects a function pointer.

Last night, however, I had a eureka moment and figured this one out. To get a reference to the current function we’re going to harness exceptions and the information we can get from the stack.

<cffunction name="getStackFunction" access="public" returntype="any" output="false">
   <cfargument name="name" type="string" required="true">
   <cfargument name="depth" type="numeric" required="false" default="1">

   <cfset var TemplateClassLoader = createObject("java","coldfusion.runtime.TemplateClassLoader")>
   <cfset var servletContext = getPageContext().getServletContext()>
   <cfset var templatePath = "">
   <cfset var TemplateClass = "">
   <cfset var field = "">

   <cftry>
      <cfthrow type="Exception">

   <cfcatch type="any">
      <cfset templatePath = cfcatch.tagContext[depth+1].template>
   </cfcatch>
   </cftry>

   <cfset TemplateClass = TemplateClassLoader.findClass(servletContext,templatePath)>
   <cfset field = TemplateClass.getDeclaredField(arguments.name)>
   <cfset field.setAccessible(true)>

   <cfreturn field.get(TemplateClass.newInstance())>
</cffunction>

We can then use this code with the (case sensitive) name of the function in the current stack to get a pointer to that function.

<cffunction name="test" myAttribute="1" output="false">
   <cfargument name="x" type="numeric">
   <cfset arguments.callee = getStackFunction("test")>
   <cfreturn arguments.x + getMetaData(arguments.callee).myAttribute>
</cffunction>

You can use the depth parameter to get functions farther down the stack as well.

I’ll go over how to build proper closure constructs using this technique, and some other novel ones that don’t even require runtime magic in an upcoming post.

Oh, and hats off to Ben for sparking my interest in this issue again! :)

This seemed to cause file locking issues in cfimage which I was told were addressed by CF 8.0.1 Cumulative Hot Fix 1. I applied the hot fix and everything seemed to work, but then when I started testing with the large file again the CPU would jump to 100% and the request would never seem to finish. I tried all kinds of things, and nothing I did seemed to make a difference.

Finally I tried the “highestPerformance” interpolation and the requests started finishing hundreds of times faster. Any other interpolation algorithm seems to cause the thread to lock up.

I’ve fixed this in our code with:

<!---
	CF8 will peg the CPU to 100% and this thread will seem
	to hang for minutes on large images if we don't choose
	highestPerformance.
--->
<cfif getSize("kilobytes") gt 375>
	<cfset arguments.interpolation = "highestPerformance">
</cfif>

What’s most odd is that the issue only appears on Windows on the production server. On my Macbook I can choose a different algorithm and get a nice resize without hanging the request.

Production server is Java 1.6 u11, CF8.0.1 HF2, Windows Server 2003

Anyone have any ideas?

So CF8 outputs the cfcatch.message into the Reason-Phrase portion of the HTTP Response, however it does not strip new lines (LF or CR). A web server, however, should never send new lines in the Reason-Phrase [1], and should probably be truncating that error message at a certain length.

[1] RFC2616, Section6, HTTP Response

It’s pretty easy to reproduce this bug:

<cfthrow message="foo #chr(10)##chr(10)##chr(10)# bar">

Another way to show this is with the new deserializeJSON() function in CF8 when the JSON is not valid. CF outputs the exception message with the JSON into the Reason-Phrase portion of the HTTP response Status-Line without stripping out new lines.

ColdFusion Code

<cfset json = '
{
    "foo": [
        {}
        "",
        {
            "f": {}
        }
    ]
}
'>

<cfset deserializeJSON(json)>

And the server responds with:

HTTP Response

HTTP/1.1 500 JSON parsing failure: Expected ',' or ']' at character 20:'"' in {
	"foo": [
		{}
		"",
		{
			"f": {}
		}
	]
}
Date: Wed, 01 Aug 2007 05:31:39 GMT
Server: Apache/1.3.33 (Darwin) mod_fastcgi/2.4.2 PHP/5.2.0 JRun/4.0
server-error: true
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

<!-- " ---></TD></TD></TD></TH></TH></TH></TR></TR></TR></TABLE></TABLE>

As it stands now, if you had 100 lines of JSON and there’s an error at the end, CF will dump all previous lines of JSON into the http Reason-Phrase.

This is particularly apparent in Safari (and WebKit based browsers) where it actually displays the HTTP headers in the body of the page because it sees new lines and assumes the HTTP headers are complete, and worse in Gecko based browsers that render the page as text/plain because the Content-Type header is never processed!

It should also be noted that CF7 output “Internal Server Error” for the Reason-Phrase instead of the exception message.

There also seems to be some other random junk thrown into the page when an exception is thrown….

foo bar baz<cfthrow message="foo #chr(10)##chr(10)#bar">

Will generate the following right after the http headers:

b
foo bar baz
1f27

I hope this saves someone some time trying to figure out what’s going on on their code! :)