Performance-Aware e Coding Guidelines – Part 3

The constraint solver is a powerful and fun to use tool.  Actually, it is so much fun that  sometimes people tend to use it in cases where generation is not required.  Of course, like any other algorithmic engine, the “price” of using the constraint solver is paid in performance – both memory and CPU.  This price is acceptable whenever the solver is used to process complicated generation problems, but it’s way too expensive when you do not really need the solver’s power.

Fortunately, there is a simple rule you can follow: the constraint solver should not be used when the items are created procedurally. 

The potential “gotcha” here is that sometimes procedural creation can be disguised as generation.  Watch out for these cases:

• Fields that are computed and assigned in post_generate()
There is no need to generate such fields, and then overriding them with procedural code. Just mark these fields as do-not-generate (using the “!” operator).

• Monitored data items
These fields are assigned procedurally during item collection, using unpack() and other procedural means. By using a simple new statement, you create the data item quickly without any solver overhead.

• Methods return value
I’ve seen cases in which the return value of a method was generated using a single equality constraint. For example, “gen result keeping {it == (my_value == expected_value)};”. Why? A “result = (my_value == expected_value);” gives exactly same outcome with much less overhead.

In the next segment of the series I’ll reveal some performance secrets using the new Sequences API.  Stay tuned …

Efrat Shneydor
Methodology R&D

Reference links to prior posts in this series: 

Part 1 on improving the performance of Lists

Part 2 on memory savings from proper Base types extensions and using CONST fields