Jun 22 2006

Model-Glue:Unity gets faster!

Posted by Joe Rinehart at 7:49 AM
15 comments
- Categories: Model-Glue

After Sean Corfield clued me in to the performance impact of things like DuckTyping instead of strict typing in low-level code (like frameworks), I made some large changes to the Model-Glue:Unity core in terms of arguments and returntypes.

The result: whoa, that's fast.

Here's a few benchmarks from a 100-concurrent-user load test:

Application Template

Model-Glue 1.1 - 3095ms avg. request time

Model-Glue 1.1.1 RC1 - 1428

Model-Glue:Unity Beta 1 - 1430

Model-Glue:Unity BER - 596

Petmarket

Model-Glue 1.1.1 RC1 - 2892ms avg. request time

Model-Glue:Unity Beta 1 - 2602

Model-Glue:Unity BER - 2115

Lesson learned: ColdFusion checks metadata for typing and requirements at runtime. If you're in situation where every ms counts (like the Model-Glue request lifecycle), you may want to thing about loosely typing your code.

Comments

Peter Bell

Peter Bell wrote on 06/22/06 9:00 AM

Hello Joe,

Just to clarify, CF runs metadata type checking at runtime which can affect performance. Right?

Couple of questions:
How do you do loose typing?
- Returntype = any for methods
- Argument type = any for cfarguments
Anything else?

Also, I'm guessing this is not limited to instantiation of objects so object caching wouldn't avoid this problem - it would be every method call that would be slower - right?

As an associated question, any idea of the performance hit for using beans in your displays rather than queries or structs (First Name: #ThisUser.getFirstName()# instead of First Name: #FirstName#)? I'd always heard it was nominal, but if you're displaying collections of objects (vs. outputing from a cf query) is object instantiation time not the only thing you have to worry about from a performance perspective?

Any of Seans tips you could pass along would be much appreciated!

Best Wishes,
Peter
Yacoubean

Yacoubean wrote on 06/22/06 10:06 AM

I think my question is the same as part of Peter's, but mine's much more simple (because I'm pretty slow :) ). If I understand you're post right, duck typing is faster than strict typing in ColdFusion? That seems strange, because CF has to do some work under the covers to properly handle a loosely typed variable, but at the same time your explanation makes sense. I just wanted clarification.
Ryan Guill

Ryan Guill wrote on 06/22/06 11:03 AM

No Yacubean, CF has to do more work with strict typing because it is having to enforce the typing. With duck typing, it only has to enforce what you are doing with the arguments after they get into the method.

Joe, what are you using to simulate a 100-concurrent user load?

And yeah peter, it seems it would be a problem even if you are caching the object somehow because the hit is not in the initialization of the object, it is when you are calling a method.
Peter Bell

Peter Bell wrote on 06/22/06 11:33 AM

Hi Ryan,

Here's what I'm trying to understand due to my lack of knowledge about how both CF and Java actually work . . .

Java is strongly typed. I had assumed it also compiled down to strongly typed bytecode. Hence I assumed that strongly typing your CF code would if anything improve performance as it would stop the CF compiler from having to figure out the type of everything and pass that in.

I know that logic is flawed/simplistic, but would really like to understand why! Is Java bytecode NOT strongly typed - it typing just a compiler thang in Java?

What am I missing?! (BTW - Ryan - hope you'll be at CF United - would love to grab a beer!)

Best Wishes,
Peter
Ryan Guill

Ryan Guill wrote on 06/22/06 11:54 AM

No, you are right, the java bytecode is strongly typed. But the crux here is that when you specify a type on an argument, colfusion checks the metadata of that variable/object and checks the type, and then it goes down to java bytecode where it is probably getting checked again. But that second part, coldfusion is handling for us anyway, and there really is no way around it. So what you get (and I am no expert on this, this is purely speculation) is that that second step of going from coldfusion down to the bytecode is going to happen regardless. By specifying type of any though, you keep coldfusion from doing that first check which speeds up the application.

And so, what we get then is actually a better thing if you think about it... if for some reason the argument needs to be of a certain type, numeric for instance, when you go to use the argument in a function or passing into a query. If it is the wrong type, then it will throw an error there, instead of on the way into the method in the first place.

So, you can do your own checking if aboslutely necessary, and using try/catch, you can catch and throw friendly errors instead passing back out of the method if necessary. So what you have then is all of your error catching inside of your business logic instead of the calling code... which is a better thing all around more than likely.

somebody please correct me if I am wrong about any of this...

unfortunately no, im not going to be at cfunited, which I am rather bummed about btw. I owe you a beer though next time I see you. I do have a collegue going in my place though, so ill send him some money to buy you a beer instead!
Matt Williams

Matt Williams wrote on 06/22/06 3:13 PM

It would be interesting to know if pre-defined data types such as 'numeric', 'string', and 'struct' differ in type validation from customized object types such as 'Person' or 'ShoppingCart'.

I agree with Ryan that we should be using try/catch in testing for the data type. This should probably be the case if we specify type="any" or type="numeric" for better handling.

And Peter, it is something to think about concerning the "return a bean or a return a query" question. I think it comes down to which is easier to maintain or maybe which better fits the application at hand. If performance were the only concern in life, shouldn't we all use Java or C/+/++? (rhetorical question, please don't flame)
Sean Corfield

Sean Corfield wrote on 06/22/06 4:57 PM

I was hoping Joe wouldn't let the cat out of the bag before CFUNITED about this since I'm going to be covering this in my "Heresy! Embracing Duck Typing in CFCs" talk (which was originally going to be Hal's talk).

Stop speculating about how CF represents variables and types - you're all wrong to varying degrees :)

After CFUNITED, I'll post my talk and then I'll be happy to answer questions on this. For now, just accept that Joe has made a number of changes that replace "strict" typing with "loose" typing and Model-Glue is faster as a result. I "discovered" this while I was tuning Fusebox 5 for Beta 2 and let Joe know about it so he was able to do the same stuff to Model-Glue. I bet Mach II could benefit from this as well.

More at CFUNITED and lots about it afterward.
barry.b

barry.b wrote on 06/22/06 8:48 PM

it's like COM's early- Vs late-binding all over again. References Vs Runtime. except (IIRC) COM early binding was faster (for totally different reasons).

sure Duck-typing is relavant but it also seems like spin to make up for people wanting to make CF work like (strongly-typed) Java or C# - and can't.

is this one more argument in not using strongly typed CFC's at all?
Sean Corfield

Sean Corfield wrote on 06/23/06 12:37 AM

Barry, as a C++ / Java developer coming to ColdFusion, I was a strong advocate of adding interfaces and the like to ColdFusion at first. But I also have a background in typeless languages (both functional languages and OO languages) and gradually that has reasserted itself in my dealings with ColdFusion and I'm moving increasingly to a typeless model again, supported by strong unit testing.
barry.b

barry.b wrote on 06/23/06 12:57 AM

> I'm moving increasingly to a typeless model again, supported by strong unit testing.

which *does* sound like the smartest way of all, considering the lack of compile-time checking.

it's just that I'm comming out of a C# project (objects and type-checking everywhere) ready to start another CF one and thinking "this time I'll do everything right and use strict-typed CFC's!"

in other words, this post is very timely. thanx Joe.
Peter Bell

Peter Bell wrote on 06/23/06 8:48 AM

Hi Sean,

You tease!

I'm very glad Joe let the cat out of the bag. I'd seen Hals presentation at cf.objective() so I wasn't planning to attend again. Now I'm looking forward to the talk (please tell me this isn't all just a sinister hoax to make you "most popular presenter" again!) :->

BTW, we'll stop speculating when y'all put out a white paper on the topic. I know you're not in the CF group, but you're a manager damn it (:->). Can't you pointy hair us up a white paper from the CF team?!

Ryan, sorry to hear you won't be there. Will remember to raise a glass to absent friends. Maybe cf.objective next year?!

Matt, you're absolutely right about performance. But after some traumatic early experiences when I tried to generate entire applications on the fly pulling all the metadata at runtime from a remote database (I was younger and even more foolish back then) I'm a little sensitive about performance!

Barney - I'm with you. I am rewriting all my generation templates to work in a nice OO way (as close as I can figure out what a nice OO way should be). I KNOW I only have one template for DAO's, one for Gateways rather than a whole application, but I'd still hate to get all my typing in and find I was generating the framework equivalent of frozen molassas!
Jason

Jason wrote on 06/23/06 9:06 AM

So, Joe, any ETA on when a new build of M-G 2 Beta will be available so we can play with the new speed?? Recently ported a substantial 1.1 app to 2 Beta and I'm liking what I see. Also built a quick app from scratch to test the scaffolding / reactor stuff, and I must say it rocks out loud.

Thanks!
Bill

Bill wrote on 06/30/06 3:31 PM

not a MG comment sorry but about the blog - the comments window opens in a dialog that is too narrow in Firefox - all of the paragraphs are cut off on the right. I lose about 3 words from each line.
acer battery

acer battery wrote on 09/27/08 11:38 PM

http://www.batteryfast.com/hp/xe3b.htm hp xe3b battery,
http://www.batteryfast.com/hp/xe3c.htm hp xe3c battery,
http://www.batteryfast.com/hp/xe3l.htm hp xe3l battery,
http://www.batteryfast.com/hp/f2024.htm hp f2024 battery,
http://www.batteryfast.com/hp/f2024b.htm hp f2024b battery,
http://www.batteryfast.com/hp/dv8000.htm hp dv8000 battery,
http://www.batteryfast.com/hp/dv8100.htm hp dv8100 battery,
http://www.batteryfast.com/hp/dv8200.htm hp dv8200 battery,
http://www.batteryfast.com/hp/dv8300.htm hp dv8300 battery,

http://www.batteryfast.com/hp/hstnn-db20.htm hp hstnn-db20 battery,
http://www.batteryfast.com/hp/nx6120.htm hp nx6120 battery,
http://www.batteryfast.com/hp/pb994a.htm hp pb994a battery,
http://www.batteryfast.com/hp/nc6100.htm hp nc6100 battery,
http://www.batteryfast.com/hp/nc6120.htm hp nc6120 battery,
http://www.batteryfast.com/hp/nx6100.htm hp nx6100 battery,
http://www.batteryfast.com/hp/6515b.htm hp 6515b battery,
http://www.batteryfast.com/hp/nx6325.htm hp nx6325 battery,
http://www.batteryfast.com/hp/hstnn-db11.htm hp hstnn-db11 battery,

http://www.batteryfast.com/hp/nc8230.htm hp nc8230 battery,
http://www.batteryfast.com/hp/nc8200.htm hp nc8200 battery,
http://www.batteryfast.com/hp/nw8200.htm hp nw8200 battery,
http://www.batteryfast.com/hp/nx8200.htm hp nx8200 battery,
http://www.batteryfast.com/hp/nc8430.htm hp nc8430 battery,
http://www.batteryfast.com/hp/pb992a.htm hp pb992a battery,
http://www.batteryfast.com/hp/nc6000.htm hp nc6000 battery,
http://www.batteryfast.com/hp/nx5000.htm hp nx5000 battery,
http://www.batteryfast.com/hp/nw8000.htm hp nw8000 battery,
parth

parth wrote on 09/29/08 4:28 AM

BTW, we'll stop speculating when y'all put out a white paper on the topic. I know you're not in the CF group, but you're a manager damn it (:->). Can't you pointy hair us up a white paper from the CF team?!
http://www.batteryfast.co.uk/hp/xe3b.htm hp xe3b battery,
http://www.batteryfast.co.uk/hp/xe3c.htm hp xe3c battery,
http://www.batteryfast.co.uk/hp/xe3l.htm hp xe3l battery,
http://www.batteryfast.co.uk/hp/f2024.htm hp f2024 battery,
http://www.batteryfast.co.uk/hp/f2024b.htm hp f2024b battery,
http://www.batteryfast.co.uk/hp/dv8000.htm hp dv8000 battery,
http://www.batteryfast.co.uk/hp/dv8100.htm hp dv8100 battery,
http://www.batteryfast.co.uk/hp/dv8200.htm hp dv8200 battery,
http://www.batteryfast.co.uk/hp/dv8300.htm hp dv8300 battery,

http://www.batteryfast.co.uk/hp/hstnn-db20.htm hp hstnn-db20 battery,
http://www.batteryfast.co.uk/hp/nx6120.htm hp nx6120 battery,
http://www.batteryfast.co.uk/hp/pb994a.htm hp pb994a battery,
http://www.batteryfast.co.uk/hp/nc6100.htm hp nc6100 battery,
http://www.batteryfast.co.uk/hp/nc6120.htm hp nc6120 battery,
http://www.batteryfast.co.uk/hp/nx6100.htm hp nx6100 battery,
http://www.batteryfast.co.uk/hp/6515b.htm hp 6515b battery,
http://www.batteryfast.co.uk/hp/nx6325.htm hp nx6325 battery,
http://www.batteryfast.co.uk/hp/hstnn-db11.htm hp hstnn-db11 battery,

http://www.batteryfast.co.uk/hp/nc8230.htm hp nc8230 battery,
http://www.batteryfast.co.uk/hp/nc8200.htm hp nc8200 battery,
http://www.batteryfast.co.uk/hp/nw8200.htm hp nw8200 battery,
http://www.batteryfast.co.uk/hp/nx8200.htm hp nx8200 battery,
http://www.batteryfast.co.uk/hp/nc8430.htm hp nc8430 battery,
http://www.batteryfast.co.uk/hp/pb992a.htm hp pb992a battery,
http://www.batteryfast.co.uk/hp/nc6000.htm hp nc6000 battery,
http://www.batteryfast.co.uk/hp/nx5000.htm hp nx5000 battery,
http://www.batteryfast.co.uk/hp/nw8000.htm hp nw8000 battery,

http://www.batteryfast.co.uk/hp/nc8000.htm hp nc8000 battery,
http://www.batteryfast.co.uk/hp/v1000.htm hp v1000 battery,
http://www.batteryfast.co.uk/hp/nx4300.htm hp nx4300 battery,
http://www.batteryfast.co.uk/hp/b1800.htm hp b1800 battery,
http://www.batteryfast.co.uk/hp/hstnn-a14c.htm hp hstnn-a14c battery,
http://www.batteryfast.co.uk/hp/b1829tu.htm hp b1829tu battery,
http://www.batteryfast.co.uk/hp/b2000.htm hp b2000 battery,
http://www.batteryfast.co.uk/hp/hstnn-b071.htm hp hstnn-b071 battery,
http://www.batteryfast.co.uk/hp/lb32111b.htm hp lb32111b battery,

Write your comment



(it will not be displayed)