this is exactly what I did. It was a very quick benchmark and this is the usual technique I use as well. I do usually execute these tests on a *nux-based machine, as I find the accuracy of system.currentTimeMillis() to be a little better there. As long as the you make the number of executions very big, it doesn't really make a difference anymore however…

One thing you have to keep in mind: micro benchmarks are not really useful if you *really* want to know about the performance of a specific operation. A micro benchmark ignores a lot of stuff such as concurrency, the difference in platforms you run the benchmark on, et cetera… So this is really only indicative.

-Cliff

How do you intend on designing this benchmark? Now _that_ would be something to blog about. You might get good feedback on how to design or improve the quality of the benchmark, too.

John,

I hope you realize that my goal of this blog entry was to actually point out that a I'm not going to do a benchmark as it is irrelevant. Of course, from a theoretic standpoint it would definitely be a nice exercise, but unfortunately I (and I think neither does any of my colleagues) don't have time for this…

regards,
Alef

Thanks a lot for this great article.

Thanks Maz. I appreciate that.

On July 24, 2007 at 8:32 am, Maz Rashid said:

BTW, debuging Marcs code I was really surprised to discover that hibernate (assuming using cglib) will also create proxies for abstract classes and the AbstractMethodError is thrown later when you really call a method. Is it a bug or feature? (not a serious question

Hmm, interesting. I never noticed this behavior. Of course it's possible and technical totally understandable (yes, by default Hibernate uses CGLIB unless you specify otherwise), but I would argue that this is not the behavior that you'd expect as a user…

On July 24, 2007 at 8:32 am, Maz Rashid said:

1. A mediate C -Compiler is capable to detect empty functions and eliminate them. In Java the at least hotspot compiler would do this by inlining the empty block, so no time should be consumed calling the empty function after a given number of calls.
Have you considered this in your micro benchmark? (So the function should count a counter or something like that to avoid compiler/hotspot optimization and counting the call time after the hotspot optimisation is in place?)

When I have time I'll try to have a look at the small benchmark that I prepared. Of course my whole point was that performance doesn't really matter , but I understand that this can have a big impact. I'll probably have to update the article anyway after some other comments, so I'll try to incorporate that in a future revision.

On July 24, 2007 at 8:32 am, Maz Rashid said:

2. My Feeling is that obsessive usage of proxies will hinder compiler optimization as the compiler always will end up on interfaces and the link to the implementation is only available in the application-context.xml. And the usage of reflection is also not supporting the hotspot compiler.
Do you agree or are there any discussions covering this topic?

That's an interesting suggestion. I'm not about this, I wish I was a compiler expert but unfortunately, I'm not . At first sight, I would agree. I've forwarded this to some other guys, let's see what they come up with.

Thanks a lot for this great article.
I had this discussion recently with Marc and I think he missed the point.

First of all I love Spring at all and want to use this opportunity to thanks all you guys for this great work. I already have realized two big pan european projects with Spring and I am also aware of the based technology for the Spring factory framework.

The point was, that Marc just joined the team when our project was in the last days of the test phase and no big changes were expected to be done and commited buggy code which broke the build.

I thought that I had made clear that the main issue was, that breaking the build just before delivering is not a good idea.
Beside that one of my last points was, that springifying that particular class would not make any sense as no of the mentioned advantages would apply and then you have only to pay the overhead.
That's it. Thanks for backing up my position.

BTW, debuging Marcs code I was really surprised to discover that hibernate (assuming using cglib) will also create proxies for abstract classes and the AbstractMethodError is thrown later when you really call a method. Is it a bug or feature? (not a serious question

But reading your article I have some particular questions helping me to see some issues more clearly:

1. A mediate C -Compiler is capable to detect empty functions and eliminate them. In Java the at least hotspot compiler would do this by inlining the empty block, so no time should be consumed calling the empty function after a given number of calls.
Have you considered this in your micro benchmark? (So the function should count a counter or something like that to avoid compiler/hotspot optimization and counting the call time after the hotspot optimisation is in place?)

2. My Feeling is that obsessive usage of proxies will hinder compiler optimization as the compiler always will end up on interfaces and the link to the implementation is only available in the application-context.xml. And the usage of reflection is also not supporting the hotspot compiler.
Do you agree or are there any discussions covering this topic?

Great thanks in advance
Maz
http://www.mazcity.de

I\'m inexperienced, so I apologize if my points seem sophomoric. That said…

Does it make sense to compare dynamic proxies to bytecode weaving? In other words, are you inadvertently talking past whether this is even a debate? I do not know, so let us discuss it and perhaps agree on an answer.

Bytecode weaving just means that bytecode is weaved into the class file generated by the compiler. AspectJ supports compile-time, post compile-time and load-time weaving. Classes can be instrumented with extra behavior at any of these points and ajc even supports subsequent reweaving by default.

A proxy, on the other hand, is a surrogate object used to control access to the real object.

Are these two concepts mutually exclusive? Although you did not directly state so, you did mention an 80/20 split between the proxy design technique and bytecode weaving technique. You seem to have set forth an assumption that these concepts are mutually exclusive.

I\'m testing your assumption because it simply doesn\'t sound right to me, albeit I\'ve never been forced to think in these terms before, perhaps neither have you. It sounds like you are thinking at the implementation level, in the language of Java, rather than thinking about the problem at a higher level. What might be a good high level model of this problem? In order to describe this problem, I think you need a modular system in place to control the routing of messages. Modular is important, because it means you must be able to both add and take away from the message routing system. In my humble opinion, this is exactly what aspect-oriented programming seeks to address.

You\'ve nailed it! I think your last paragraph is possibly one of the better explanations of the difference between AOP and proxies (or least, the difference in the level of the two concepts).

So yes, on a conceptual (or higher) level, it does absolutely not make sense to compare the two, only on an implementation level and this is exactly what I was trying to achieve. I should probably make that a little bit more explicit. I think I have to rewrite some of this including a clearer distinction between the levels of abstraction we\'re talking about.

In other words: you\'re totally right . And no, the two are definitely not mutually exclusive.