Issue #4040 indicated that memory usage related to log/report generation may have increased after RF 3.2. That wasn't certain based on the issue description, but profiling by running /usr/bin/time -v rebot output.xml with output.xml containing 1000 dummy test cases showed that maximum memory sure enough had raised from ~102MB with RF 3.2.2 to ~123MB with RF 4.1.1. Unfortunate /usr/bin/time -v doesn't show where the memory is spent, but git bisect revealed that the commit causing pretty big increase in memory usage was 21c6b46.

The aforementioned commit added direct setup and teardown attributes to TestSuite and TestCase objects and teardown to Keyword. That was a good change from the API point of view, but each TestSuite and more importantly TestCase always having setup and teardown that are represented as Keyword objects takes some memory. With Keyword objects teardown is actually only created if needed, so I figured that there wouldn't be problems with them. Reverting the API change just to make TestCase objects use a little less memory didn't feel like a good idea.

Yesterday I totally by accident encountered a Python memory profiler called Fil. I had searched for this kind of tools earlier, but hadn't found this one. It looked really promising and targeted for exactly in our kind of use case. According to Fil docs it helps us to figure out:

• Where peak memory usage is, also known as the high-water mark.
• What code was responsible for allocating the memory that was present at that peak moment.

Turned out Fil did what it promised and I was able to find few places where we use lot of memory and where the memory usage has increased from RF 3.2.2. The biggest problem was that Keyword.teardown which I though wouldn't matter. It's true it's only created when needed, but we accessed kw.teardown in few central places (e.g. in SuiteVisitor) and that was enough. I commit a fix to this problem and to others I encountered separately.

After profiling and tuning the memory usage has dropped considerably on my machine. Usage reported /usr/bin/time -v with the same test set I used earlier is now ~83MB. That's a huge from from ~123MB with RF 4.1.1 and also a big drop from ~103MB with RF 3.2.2. If I got my math right, with this set memory usage has dropped 33% compared to RF 4.1.1 and 20% compared to RF 3.2.2.

Although these changes are pretty small, they still require new RF 4.1.2 release candidate and may require postponing the final release few days. Considering how big enhancements are, I consider that worth it and better than waiting for RF 5.0.