From: Eric T. <et...@dc...> - 2006-01-31 17:29:16
|
Hi, On Jan 31, 2006, at 13:23 , Renaud Pawlak wrote: >> The JoinPoint implementation is also not based on =20 >> java.lang.reflect under the covers (you state otherwise). > > Ooops! I will change it, but I would be very interested in knowing =20 > exactly how it is done then, because I lack time to dive into =20 > AspectJ sources... Note that java.lang.reflect is very optimized =20 > nowadays and that's why I assumed that it was use here. I'm surprised. Just to add a bit on that. In previous versions of Reflex we used the reflection API for =20 proceed, assuming it was sufficiently optimized. Then we did some =20 benchmarks on AspectJ-over-Reflex vs. AspectJ alone, and had =20 reasonable 10-15% overhead for most cases, as was to be expected, =20 except precisely for the cases with proceed [1]. We therefore assumed =20= the use of java.lang.reflect was the source of overhead. We have now =20 implemented the same optimization as in AspectJ (ie, generate stub =20 methods that do proceed "directly") and got very good results. So btw, apart from the fact that the reflective API is not as =20 efficient as one would (like to) believe, there are other AOP systems =20= that do not rely on it. AspectJ is one, Reflex is another, and there =20 might be others as well. -- Eric [1] L. Rodr=EDguez, =C9. Tanter, J. Noy=E9 - "Supporting Dynamic =20 Crosscutting with Partial Behavioral Reflection: A Case Study", =20 Proceedings of SCCC 2004 (extended/corrected version in French to =20 appear in l'Objet). |