thanks, I am working on a comparison of Peaberry and Spring DM and iPOJO and the service proxy overhead should help.

Hey if this comparison is going to be accessible online please post a message in this projects forum. I myself had to pick between iPojo and Peaberry for a project and did an ad-hoc comparison. Peaberry won :P

it's not finished yet and it's not clean. I'll post it while terminated, in my tests too peaberry was better than iPOJO, but I found that Spring DM is the most complete one.

I'll look forward to reading your comparison when it's ready, in the meantime feel free to raise issues to make peaberry more complete :) Todor's lifecycle issue (10) should also help with this...

Just as a side-note (a rather long one :)

I think the killer-mix that Peaberry offers is

- Total dependency injection: you can start from the core set of singletons and continue to DI the shorter-living generations of objects. Both iPojo and Spring DM seem to concentrate on injecting only the longest living objects - they call them components. As for the others - it is possible but not easy. I think Spring even discourages the practice.

- Seamless dynamics: Wraps the services in proxies so you can pass them around the bundle and have OSGi dynamics support everywhere. iPojo instruments only the implementation class of the component. You have to hand-code proxies if you want to pass services to collaborating objects. Lately (perhaps due to my questions about it :) Clement has extended the Temporal Dependency of iPojo to do seamless proxying but I have not had the time to check it out. Spring DM uses dynamic proxies like Peaberry as the benchmarks above testify :)

These two features allow you to introduce safe services into the bundle space and than inject them directly to the points of use. Having just safe services will make you code fire-brigades to pass them from object to object until they reach the point of use. Having only DI will plainly not work because you can not "outject" the service objects when they become invalid. But put them together the sum seems to be greater than the parts :P

I have some questions about the design of the benchmark. I have a micro-benchmark of my own I use to test some proxying schemes but I never really trusted it. So I want to learn more about yours if you don't mind :)

1) Why use

Math.exp(val Math.cosh(val));

rather than just

val Math.cosh(val);

When I used the simpler expression the percentage differences between the things I test changed by about 5-7%. I suppose you were looking for a piece of code that has the same performance given the same input and is complicated enough to fool the JIT not to optimize it away during warm up. But why this exact expression? :)

2) Why at the end of the benchmark you don't do anything with the "value" dummy variable? The JIT seems to not pick this up and optimize the entire loop away. When I print the value on the screen nothing changes :) Yet once I used integer arithmetic for a benchmark and unless I printed the dummy accumulator on the screen the results were erratic :P

About the benchmark code:

1) I use nested Math calls for two reasons: one is that it stops the JIT from doing too much optimization, another is that the function takes a reasonable amount of time without making the test take ages for thousands of calls, or create large numbers of objects which can trigger GC. But it's not ideal ;)

2) The JIT doesn't know if the compute() method has any side-effect as we're calling it via an interface, so it cannot optimize away this method call.

The most important thing is that the direct and proxied calls use the same implementation underneath - of course there are still many things that can disturb the timing (GC, background JIT compilation, OS, etc.) but I'm really looking at the order of magnitude rather than the exact numbers.

HTH

Hi,

I agree that the iPOJO temporal injection using dynamic proxy was a nightmare in term of performance. It was a temporary solution (and was developped as a temporary solution). As iPOJO is based on ASM, they are now using ASM (as in peaberry).

I also quickly extend the bench to add three iPOJO based benchs : - Service Dependency (field injection, not proxy) - Temporal Service Dependency (field injection, not proxy) - Proxied Temporal Dependency (ASM proxy)

Here are the results: Guice-Peaberry: 276.00 ns/call iPOJO Service Dependency: 118.00 ns/call Spring-DM: 2384.00 ns/call iPOJO Temporal Dependency: 159.00 ns/call iPOJO Temporal Dependency with proxy injection: 173.00 ns/call

If somebody is interested by the code I can put it somewhere. I just use the iPOJO API to declare my component types as peaberry does (it is closer to the Dependency Manager than peaberry).

Clement