Is template "metaprogramming" in Java a good idea?

Question

There is a source file in a rather large project with several functions that are extremely performance-sensitive (called millions of times per second). In fact, the previous maintainer decided to write 12 copies of a function each differing very slightly, in order to save the time that would be spent checking the conditionals in a single function.

Unfortunately, this means the code is a PITA to maintain. I would like to remove all the duplicate code and write just one template. However, the language, Java, does not support templates, and I'm not sure that generics are suitable for this.

My current plan is to write instead a file that generates the 12 copies of the function (a one-use-only template expander, practically). I would of course provide copious explanation for why the file must be generated programmatically.

My concern is that this would lead to future maintainers' confusion, and perhaps introduce nasty bugs if they forget to regenerate the file after modifying it, or (even worse) if they modify instead the programmatically-generated file. Unfortunately, short of rewriting the whole thing in C++, I see no way to fix this.

Do the benefits of this approach outweigh the disadvantages? Should I instead:

• Take the performance hit and use a single, maintainable function.
• Add explanations for why the function must be duplicated 12 times, and graciously take the maintenance burden.
• Attempt to use generics as templates (they probably don't work that way).
• Yell at the old maintainer for making code so performance-dependent on a single function.
• Other method to maintain performance and maintainability?

P.S. Due to the poor design of the project, profiling the function is rather tricky... however, the former maintainer has convinced me that the performance hit is unacceptable. I assume by this he means more than 5%, though that is a complete guess on my part.

---

Perhaps I should elaborate a bit. The 12 copies do a very similar task, but have minute differences. The differences are in various places throughout the function, so unfortunately there are many, many, conditional statements. There are effectively 6 "modes" of operation, and 2 "paradigms" of operation (words made up by myself). To use the function, one specifies the "mode" and "paradigm" of operation. This is never dynamic; each piece of code uses exactly one mode and paradigm. All 12 mode-paradigm pairs are used somewhere in the application. The functions are aptly named func1 to func12, with even numbers representing the second paradigm and odd numbers representing the first paradigm.

I'm aware that this is just about the worst design ever if maintainability is the goal. But it seems to be "fast enough", and this code hasn't needed any changes for a while... It's also worth noting that the original function has not been deleted (although it is dead code as far as I can tell), so refactoring would be simple.

Answer 1

This is a very bad situation, you need to refactor this ASAP - this is technical debt in it's worst - you don't even know how important the code really is - only speculate that it's important.

As to solutions ASAP:
Something that can be done is adding a custom compilation step. If you use Maven that is actually fairly simple to do, other automated build systems are likely to cope with this as well. Write a file with a different extension than .java and add a custom step that searches your source for files like that and regenerates the actual .java. You may also want to add a huge disclaimer on the auto-generated file explaining not to modify it.

Pros vs using a once-generated file: Your developers will not get their changes to the .java working. If they actually run the code on their machine before committing they will find that their changes have no effect (hah). And then maybe they will read the disclaimer. You are absolutely right in not trusting your teammates and your future self with remembering that this particular file has to be changed in a different way. It also allows automatic testing as wel, as JUnit will compile your program before running tests (and regenerate the file as well)

EDIT

Judging by the comments the answer came off as if this is a way to make this work indefinitely and maybe OK to deploy to other performance critical parts of your project.

Simply put: it is not.

The extra burden of creating your own mini-language, writing a code-generator for it and maintaining it, not to mention teaching it to future maintainers is hellish in the long run. The above only allows a safer way to handle the problem while you are working on a long-term solution. What that will take is above me.

Answer 2

Is the maintenance hit real, or does it just bother you? If it only bothers you, leave it alone.

Is the performance issue real, or did the previous developer only think it was? Performance problems, more often than not, are not where they are thought to be, even when a profiler is used. (I use this technique to reliably find them.)

So there is a possibility that you have an ugly solution to a non-problem, but it could also be an ugly solution to a real problem. When in doubt, leave it alone.

Answer 3

Really make sure than under real, production, conditions (realistic memory consumption, that triggers Garbage Collection realistically, etc), all those separate methods really make a performance difference (as opposed to having only one method). This will take a few days out of your time, but may save you weeks by simplifying the code you work with from now on.

Also, if you do discover that you need all the functions, you might want to use Javassist to generate the code programatically. As other have pointed out, you can automate it with Maven.

Answer 4

Why not include some sort of template preprocessor\code generation for this system? A custom extra build step that executes and emits extra java source files before compiling the rest of the code. This is how including web clients off of wsdl and xsd files often works.

You'll of course have the maintenance of that preprocessor\code generator, but you won't have the duplicated core code maintenance to worry about.

Since compile time Java code is being emitted, there is no performance penalty to be paid for extra code. But you gain maintenance simplification by having the template instead of all of the duplicated code.

Java generics give no performance benefit due to type erasure in the language, simple casting is used in its place.

From my understanding of C++ templates, they are compiled into several functions per each template invocation. You'll wind up with duplicated mid-compile time code for each type you store in a std::vector for example.

Answer 5

No sane Java method can be long enough to have 12 variants... and JITC hates long methods - it simply refuses to optimize them properly. I've seen a speed up factor of two by simply splitting a method into two shorter ones. Maybe this is the way to go.

OTOH having multiple copies may make sense even if there were identical. As each of them gets used in different places, they get optimized for different cases (the JITC profiles them and then places the rare cases on an exceptional path.

I'd say that generating code is no big deal, assuming there's a good reason. The overhead is rather low, and properly named files lead immediately to their source. Some long time ago as I generated source code, I put // DO NOT EDIT on every line... I guess that's save enough.

Answer 6

There is absolutely nothing wrong with the 'problem' you mentioned. From what I know this is the exact kind of design and approach used by DB server to have good performance.

They have lot of special methods to make sure they can maximize the performance for all kinds of operations: join, select, aggregate, etc... when certain conditions apply.

In short, code generation like the one you think is a bad idea. Perhaps you should look at this diagram to see how a DB solves a problem similar to yours:

Answer 7

You might want to check whether you can still use some sensible abstractions and use e.g. the template method pattern to write understandable code for the common functionality and move the differences between the methods into the "primitive operations" (according to the pattern descrition) in 12 subclasses. This will mightily improve maintainability and testability, and it might actually have the same performance as the current code, since the JVM can inline the method calls for the primitive operations after a while. Of course, you have to check this in a performance test.

Answer 8

You can solve the problem of specialized methods by using Scala language.

Scala can inline methods, this (in combination with easy higher order function usage) makes it possible to avoid code duplication for free — this looks like the main problem mentioned in your answer.

But also, Scala has syntactic macros, which makes it possible to do a lot of things with code at compile time in a type-safe manner.

And the common problem of boxing primitive types when used in generics is possible to solve in Scala, too: it can do generic specialization for primitives to avoid boxing automatically by using @specialized annotation — this thing is built into language itself. So, basically, you'll write one generic method in Scala, and it will run with the speed of specialized methods. And if you need fast generic arithmetics too, it's easily doable by using Typeclass "pattern" for injecting the operations and values for different numeric types.

Also, Scala is awesome in many other ways. And you don't have to rewrite all code to Scala, because Scala <-> Java interoperability is excellent. Just make sure to use SBT (scala build tool) for building the project.

Answer 9

If the function in question is large, turning the "mode/paradigm" bits into an interface and then passing an object that implements that interface as a parameter to the function can work. GoF calls this the "Strategy" pattern, iirc. If the function is small, the increased overhead may be significant... did somebody mention profiling yet?... more people should mention profiling.

Answer 10

How old is the program? Most probably newer hardware would remove the bottleneck and you could switch to a more maintainable version. But there needs to be a reason for maintenance, so unless your task is to improve the codebase, leave it be as it is working.