Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Run-time AOP vs Compile-time AOP

What's the advantage and disadvantage of these two type of AOP framework? I'm using Unity as my aop framework, but I guess the compile-time aop framework such as postsharp may have better performance than run-time aop framework? It looks like run-time aop framework use reflection to implement the injection.

like image 919
Allen4Tech Avatar asked Sep 12 '16 10:09

Allen4Tech


People also ask

Is Spring AOP compile time weaving?

Weaving: linking aspects with other application types or objects to create an advised object. This can be done at compile time (using the AspectJ compiler, for example), load time, or at runtime. Spring AOP, like other pure Java AOP frameworks, performs weaving at runtime.

What is the difference between Spring AOP and AspectJ AOP?

Spring AOP aims to provide a simple AOP implementation across Spring IoC to solve the most common problems that programmers face. On the other hand, AspectJ is the original AOP technology which aims to provide complete AOP solution.

What is compile time and execution time?

Compile time address binding is done before loading the program into memory. Execution time address binding is done at the time of program execution. Instructions are translated into absolute address.

What is compile time weaving?

Compile-time weaving is the simplest approach. When you have the source code for an application, ajc will compile from source and produce woven class files as output. The invocation of the weaver is integral to the ajc compilation process. The aspects themselves may be in source or binary form.


1 Answers

I am not a .NET guy, but I know the AOP world in the Java ecosystem, especially AspectJ and Spring AOP. Basically there are 4 types of aspect weaving:

  • Source code weaving: Aspect code is injected as source code statements into your application source code. This is some kind of preprocessor approach. No AOP framework in the Java world uses this approach nowadays, but there used to be some in the early days of AOP.
    • The advantage would be complete independence of any runtime libaries or special AOP compilers during runtime, if done right.
    • The disadvantage would be bloated source code and a preprocessing / code generation step before compilation. You would always need the generated source code for debugging.
  • Compile-time weaving: Aspect code is woven into your application by a special compiler.
    • The advantage is no runtime overhead for aspect weaving. The only thing you need is a small runtime library on your classpath.
    • The disadvantage is that you cannot defer the decision if you want to weave aspects into your application at all to runtime. But this is only a problem when dealing with debugging or tracing aspects not needed all the time. Another disadvantage is that this approach only works for code under your control, i.e. you need to have the source code. It does not work for 3rd party libs.
  • Binary weaving: Aspect code is woven into existing class files after compilation rather than during compilation.
    • The advantage is that it also works for 3rd party code you do not have the source code for. This approach can also be mixed with compile-time weaving. You also avoid the overhead of load-time weaving (see below).
    • The disadvantages are similar to compile-time weaving: You cannot unapply an aspect once it is woven into the code, merely deactivate its execution by pointcuts such as if(). But this can be quite efficient.
  • Load-time weaving (LTW): A weaving agent/library is loaded early when your VM/container is started. It gets a configuration file with rules describing which aspects should be woven into which classes.
    • The advantage is that you can dynamically decide if/what to weave. If done via byte-code transformation and not via dynamic proxies or reflection (see below), the resulting bytecode is equally efficient as the one created via compile-time or binary weaving. Another advantage is that like binary weaving it works for your own code as well as 3rd party code, as long as the weaving agent can "see" it, i.e. it happens in a child classloader.
    • The disadvantage is the one-time weaving overhead during application start-up because weaving is done while classloading occurs.
  • Proxy-based LTW: This special LTW form is used by Spring AOP while AspectJ does the previous 3 forms listed above. It works by creating dynamic proxies (i.e. subclasses or interface implementations) for aspect targets.
    • I cannot think of any special advantage other than maybe your framework of choice (such as Spring) happens to support it.
    • Disadvantages are limitation to public, non-static methods and runtime overhead due to the proxy-based approach. It also does not capture internal method calls, i.e. when a proxied class calls one of its own methods because those calls are not captured by the proxy. Special types of pointcuts such as constructor interception, member variable read/write access and many more are not supported, making this more of an "AOP lite" approach. But it can be sufficient for your purposes.

Generally, good aspect compilers such as AspectJ create very efficient bytecode and do not heavily rely on reflection during runtime. If your aspect framework of choice does rely on reflection, probably it is not very fast. But maybe it is fast enough, depending on how heavily you use aspects.

Probably I have written too much already, but I could write even more. This is why I am stopping now. Besides, this kind of question is not well-suited to StackOverflow because it can lead to philosophical discussions and opinion-based debates. I hope I managed to be fairly objective/impartial even so.

like image 138
kriegaex Avatar answered Oct 20 '22 06:10

kriegaex