|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Why do you think CGLib proxies are faster than JDK Proxies?
It's fairly common knowledge that CGLib provides a proxy mechanism that is faster than the JDK's built in proxying mechanism. Or is it more of an Urban myth? I decided I was going to be a good citizen and wanted a mechanism where I could quickly switch between JDK proxies and CGLib proxies in a manner similar to the way AOP frameworks typically make this a small configuration change.
I found just such a package in oranjestad commons proxy class.
What caught my attention was the performance note at the bottom, where the author indicates that in his testing he actually found JDK proxies faster. My first assumption was that this was due to poor implementation on his part but it got me thinking. I had actually never attempted to validate this urban myth before.
So a quick search on the web yielded several links that suggested CGLib is faster (most are older):One article actually provides code (independent of the Oranjestad commons proxy):Implement Your Own Proxy-Based AOP Framework.
I downloaded the this code and ran it myself. The output on my developer class laptop (IBM ThinkPad T43, Intel 2.0 GHz, 2 GBytes of RAM) was as follows:08:49:21,093 INFO [DefaultAopProxyFactory] CGLIB2 available: proxyTargetClass feature enabled
08:49:21,109 INFO [CollectionFactory] JDK 1.4+ collections available
08:49:21,109 INFO [CollectionFactory] Commons Collections 3.x available
Unproxied: 559009(ns) 5(ms)
cglib: 21374225(ns) 213(ms)
Proxy: 16506009(ns) 165(ms)
This seems totally consistent with the Oranjestad performance test. So why do we all think CGlib has faster proxies?
|
|
|
Message #231479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What JDK, CGLib version?
Well, probably proxy implementation improved in JDK 5 & 6
I remember that in my tests CGLib 1 was measurable faster then CGLib 2. I first used CGLib 1 with JDK 4, but can't remember that I compared CGLib and JDK proxy for performance.
But generally, in JDK proxy you write your method resolution code (typicaly by comparing strings), while in most cases CGLib provides you with method resolution in auto-generated byte code, which can usually be direct method call without anything else.
|
|
|
Message #231478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you think CGLib proxies are faster than JDK Proxies?
In my testing, the bytecode proxies (using Javassist, not CGLIB) were only marginally faster than dynamic proxies; the different I saw was in memory utilization, since lots of tiny arrays (for method parameters) need to be created for dynamic proxies. However, that was a couple of JDKs ago so everything will have changed.
|
|
|
Message #231486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
speed is not the only reason
When I use CGLIB (as opposed to JDK Proxy) speed is not the only criterion. One thing that I like about CGLIB is that you can proxy classes and not just interfaces as in the JDK's proxy.
|
|
|
Message #231490
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: speed is not the only reason
One thing that I like about CGLIB is that you can proxy classes and not just interfaces as in the JDK's proxy.
Indeed. That's the reason CGLIB is used in Spring AOP (abstracted away from the user, to simplify and allow for other implementation choices in future).
If you only want to proxy interfaces, dynamic proxies just come with the language and work great.
Any performance difference should be pretty minor if you're on anything but a very old JVM (1.3 vintage).
Rgds
Rod
|
|
|
Message #231494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cglib is definitely faster
I suspect you're including the proxy creation in your test and using code like this to create your cglib proxy?
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(clazz);
enhancer.setCallback(methodInterceptor);
return (T)enhancer.create();
If you're concerned about performance, whether you're using cglib or dynamic proxies, you should hold onto the proxy class and use that to create proxies instead. See the cglib-based method interception code in Guice for an example.
What matters is that cglib is faster for method interception. You only get one handler per object with dynamic proxies, which means you typically have to do at least one map lookup per method invocation. Cglib, on the other hand, lets you use separate handler for each method. This means no map lookups, and if you're not actually intercepting a method, no unnecessary overhead.
|
|
|
Message #231505
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Use ASM instead of CGLIB
If you care about performance so much you should consider using ASM instead of CGLIB. It's much harder (it looks like Assembler ;) but you gain full control of loading your classes. Of course you will encounter other problems but it will pay most probably.
|
|
|
Message #231514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Use ASM instead of CGLIB
That is why people prefer CGLIB over ASM. CGLIB basically allow you to code on plain Java without any need to learn Java bytecode. Said that, it doesn't mean that we couldn't create some reusable abstraction for creating proxies in ASM (we already have generic adapter to intercept method entry and exit points)...
|
|
|
Message #231528
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cglib is NOT definitly faster
I suspect you're including the proxy creation in your test and using code like this to create your cglib
The code is available in the links and does not include creation part in the timing as you suggest.
Java Proxies are faster. If you need to intercept with classes then CGLib makes sense since proxies can't do this, but I won't accept people saying CGLib is faster until they provide code proving it.
|
|
|
Message #231541
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Cglib is NOT definitly faster
I suspect you're including the proxy creation in your test and using code like this to create your cglib
The code is available in the links and does not include creation part in the timing as you suggest.
Java Proxies are faster. If you need to intercept with classes then CGLib makes sense since proxies can't do this, but I won't accept people saying CGLib is faster until they provide code proving it.
Didn't Crazy Bob provide a link to his code -- http://google-guice.googlecode.com/svn/trunk/src/com/google/inject/ProxyFactory.java
?
Are you saying that his code sample is NOT valid for your needs ?
Thank you,
BR,
~A
|
|
|
Message #231542
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Cglib is NOT definitly faster
Java Proxies are faster. If you need to intercept with classes then CGLib makes sense since proxies can't do this, but I won't accept people saying CGLib is faster until they provide code proving it.
I'm sorry, but Cglib is faster. I pasted an example below. Here's the final result with the "-client" JVM option:
JDK Proxy: 693,588 calls/s
CGLIB: 1,895,249 calls/s
The two are closer with the "-server" option, but cglib is still faster:
JDK Proxy: 4,462,232 calls/s
CGLIB: 5,551,438 calls/s
As I pointed out in my first message, cglib will be even faster in real world situations because it supports having a separate handler for each method.
public class ProxyPerformanceComparison {
public static void main(String[] args) throws Exception {
Callable<Integer> jdkProxy = (Callable<Integer>) Proxy.newProxyInstance(
ClassLoader.getSystemClassLoader(),
new Class[] { Callable.class },
new JdkHandler(new Counter())
);
Enhancer enhancer = new Enhancer();
enhancer.setCallback(new CglibInterceptor(new Counter()));
enhancer.setInterfaces(new Class[] { Callable.class });
Callable<Integer> cglibProxy = (Callable<Integer>) enhancer.create();
for (int i2 = 0; i2 < 10; i2++) {
iterate(jdkProxy, "JDK Proxy: ");
iterate(cglibProxy, "CGLIB: ");
System.err.println();
}
}
static final DecimalFormat format = new DecimalFormat();
static void iterate(Callable<Integer> callable, String label)
throws Exception {
int count = 10000000;
long time = System.currentTimeMillis();
int total = 0;
for (int i = 0; i < count; i++) {
total += callable.call();
}
time = System.currentTimeMillis() - time;
System.err.println(label
+ format.format(count * 1000 / time) + " calls/s");
}
static class JdkHandler implements InvocationHandler {
final Object delegate;
JdkHandler(Object delegate) {
this.delegate = delegate;
}
public Object invoke(Object object, Method method, Object[] objects)
throws Throwable {
return method.invoke(delegate, objects);
}
}
static class CglibInterceptor implements MethodInterceptor {
final Object delegate;
CglibInterceptor(Object delegate) {
this.delegate = delegate;
}
public Object intercept(Object object, Method method, Object[] objects,
MethodProxy methodProxy) throws Throwable {
return methodProxy.invoke(delegate, objects);
}
}
static class Counter implements Callable<Integer> {
int count = 0;
public Integer call() throws Exception {
return count++;
}
}
}
|
|
|
Message #231550
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Cglib is NOT definitly faster
Didn't Crazy Bob provide a link to his code --
Yes he did, and when I executed it i found that Java proxies are faster.
The point of the article is not to read someone else's results and accept their conclusions, it's to take the examples and verify for yourself.
|
|
|
Message #231553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why do you think CGLib proxies are faster than JDK Proxies?
In case anone is interested, there is a library called Jakarta Commons Proxy (it's in the sandbox) that allows you to easily switch between JDK, CGLIB, and Javassist for your proxying technology. It might be useful in benchmarking these technologies against one another.
http://jakarta.apache.org/commons/sandbox/proxy/
|
|
|
Message #231564
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: could it be differences in hardware?
Is there a difference in the hardware like CPU?
No, Cglib really is faster, unless of course you're lucky enough to have a proxy which returns the exact same value every time regardless of the method. ;)
|
|
|
Message #231598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How about this
Maybe what would be helpful is for you to explain why the code links in the article runs slower. You answered my question by sending me completely new code.
The code referenced in the article *claims* that GGLib is faster, then when you download it... it is slower. So I'd be curious why that code runs slower.
I could download your code, but you are getting into the guts of CGLib and I was hoping for a simple interface.
|
|
|
Message #231609
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: could it be differences in hardware?
Is there a difference in the hardware like CPU?
No, Cglib really is faster, unless of course you're lucky enough to have a proxy which returns the exact same value every time regardless of the method. ;)
So if I understand correctly, it runs faster for you, but not for someone else. Same code should run the same assuming the hardware is similar enough. If there's a difference, then it must be something causing it.
peter
|
|
|
Message #231616
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: could it be differences in hardware?
So if I understand correctly, it runs faster for you, but not for someone else. Same code should run the same assuming the hardware is similar enough. If there's a difference, then it must be something causing it.
peter
We didn't run the same code. Prodeep ran the code from the Javadocs he linked to in the original post, but that test isn't very realistic. I provided a different test (pasted above) which illustrates one of the places where cglib is faster.
|
|
|
Message #231618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: could it be differences in hardware?
Ah..It's the old bait and switch. First you have to prove the theory incorrect and then you get suckered in to providing a full tutorial on all technologies used in the original question posed.
....We didn't run the same code. Prodeep ran the code from the Javadocs he linked to in the original post, but that test isn't very realistic. I provided a different test (pasted above) which illustrates one of the places where cglib is faster.
|
|
|
Message #231677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: could it be differences in hardware?
So if I understand correctly, it runs faster for you, but not for someone else. Same code should run the same assuming the hardware is similar enough. If there's a difference, then it must be something causing it.
peter
We didn't run the same code. Prodeep ran the code from the Javadocs he linked to in the original post, but that test isn't very realistic. I provided a different test (pasted above) which illustrates one of the places where cglib is faster.
ok, that makes more sense. But that still doesn't help others figure out when cglib is faster and slower than java proxy.
peter
|
|
|
Message #262675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Seems like CGLib is faster
Well, I was googling to find out which one was faster and landed up on this thread. I ran the example provided by Bob and in my machine, CGLib is faster than JDK Proxy.
I used CGLib 2.2 / Java 1.6_05 on Windows XP SP2 (Core Duo 2GHz / 1GB RAM)
The result of execution was this :
JDK Proxy: 959,881 calls/s
CGLIB: 2,504,556 calls/s
|
|
|
Message #265168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
4M2: Seems like CGLib is faster
Well, I was googling to find out which one was faster and landed up on this thread. I ran the example provided by Bob and in my machine, CGLib is faster than JDK Proxy
Same here, on 2 different VMs:
Sun HotSpot Server 1.5.0_16-b02, mixed mode):
JDK Proxy: 2,937,636 calls/s
CGLIB: 6,184,497 calls/s
Sun (build 1.6.0_07-b06) HotSpot Server (build 10.0-b23, mixed mode):
JDK Proxy: 1,902,922 calls/s
CGLIB: 3,551,802 calls/s
JDK Proxy: 3,256,502 calls/s
CGLIB: 5,778,956 calls/s
Platform used: Linux 2.6.25-2-686 Debian Lenny, on Dell Precision 390, Core 2 6300@1.86Ghz
|
|
|
Message #265727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Performance Issues : Lookup method VS setter injection
I have realized significant difference in performance metrics when the non-singleton bean(prototype bean) is injected into a non-singleton OR singleton bean using setter(or property) injection and lookup method.
<bean id="myService" class="com.b.c.MyServiceImpl" singleton="false">
<lookup-method name="getAccessor" bean="myDAOImplBean"/>
</bean>
Note: myDAOImpleBean is also prototype bean
<bean id="myBean" class="com.b.c.MyBeanImpl" singleton="true">
<lookup-method name="getService" bean="myService"/>
</bean>
<bean id="myService" class="com.b.c.MyServiceImpl" singleton="false">
<property name="getAccessor" ref="myDAOImplBean"/>
</bean>
<bean id="myBean" class="com.b.c.MyBeanImpl" singleton="true">
<property name="getService" ref="myService"/>
</bean>
The injected prototype beans injects few more beans. In total, there are around 15-20 beans instantiated when getService() is being called on myBean.
So the question is,
The later approach(property injection) is taking around 500ms to create and inject the beans where as the formaer approach(lookup-method) is taking around 30ms. Significant difference...I dont find anything in Spring Docs on this topic. Wondering whether anyone of you ran into same/similar issue?
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
