Contrib equationReader/Efficiency

How fast is equationReader?

Preliminary results are in, and they are a little disappointing. equationReader seems to take between 10 to 20 times longer than a hard-coded solution, depending on the equation involved, and the type of evaluation. I will upload results of my experiment when I have the time. If you don't plan on using it within your main solver loop, this isn't a big deal, but if you do, the question is: do the benefits of flexibility outweigh the cost?

Also, expect equationReader to get faster with future updates. I used a function-pointer framework, and should have used a function object... or maybe even defined an entire set of derived objects, one for each operation type, and inlined its evaluate function.

1 Efficiency discussion

1.1 Parsing and evaluating

There is a difference between parsing and evaluating. When the equation is first read, it is a human-readable string expression. equationReader translates the human-readable form into an operation list. This is parsing. To calculate the result, equationReader does a forAll(operations, i). This is evaluating.

Parsing happens only once, and is slow. Evaluating happens at every cell index, at every timestep (or however you've used it), and it is fast.

1.2 Burn all conditionals

Conditionals are slow. In the framework of equationReader, one if or switch slows a single equation operation by about 25%. A word comparison - that slows things by over 1600%.

equationReader has a design philosophy: put no conditionals in the way of an evaluate function. To achieve this I implemented a function-pointer framework.

1.3 Function-pointers

Apparently in C++ you can have pointers to functions. The syntax looks a little odd:

       void (Foam::equationReader::*reportScalarOperationFunction_)
       (
           const label&,
           const label&
       ) const;

That's not a function - it's a pointer. You don't see these too often because C++'s virtual functions do the same thing - only you need a hierarchy of derived classes. In theory, virtual functions have slightly more overhead than function-pointers because each virtual function call requires a hash-table look-up, unlike the direct use of function-pointers.

Anyway, these function pointers can all be assigned during parsing, and called directly during evaluation. Essentially this moves all conditionals into the parser, and their result is permanently remembered. In short: these make equationReader faster.

Now, there's not a single conditional encountered during an evaluate function call. Even all the debug switches have been converted to function-pointers.

1.4 Function objects

Apparently function-pointers are old-school, and the next best thing are function-objects, or "functors". Function-objects are better because they can be inlined, unlike function-pointers. Well, I didn't get the memo until it was too late for this version. Maybe in another version.