Today I did some research into why my Drools rules were running out of heap space in Java, even though there were not many rules (less than 300), and not many objects to iterate over (less than 10,000).

I found the problem was that I was using eval() in situations where it should not be used. So I wrote up an article with lots of pretty graphs.

I have a frequently occuring problem where, during development, my system will run out of GDI handles, resulting in weird rendering problems, Eclipse not starting (org.eclipse.swt.SWTError: No more handles), and files being unable to save.

A bit of investigation shows that on Windows XP, there is a default limit of 10,000 GDI objects in the system, which can be increased to 65k (but the actual limit is below that).

The number of GDI objects in use by each process can be obtained through the Windows process manager:



As you can see, on my system the main culprits are Eclipse (2618), Windows Explorer (1821), Textpad (939) and Firefox (834).

It turns out there is already a submitted bug in Eclipse, that using the Sun JVM results in too many GDI objects being used.

EDIT: It seems that this may instead be a limitation of the desktop heap in Windows. As recommended by my good friend Patrick, you can check your desktop heap as follows:

1. Download and install the Desktop Heap Information Monitor Tool.
2. The symbols need to be installed using the following command: `dheapinst.exe -y srv*http://msdl.microsoft.com/download/symbols`
3. The monitor tool can then be used to check usage. If you are using close to the limit (I was using 94% of my default desktop heap of 3 MB), you can modify it through the registry.
   

It seems that much of my desktop heap is used by Windows Explorer windows - closing 25 of these windows resulted in close to a 40% drop in heap usage.

I was interested in improving the performance of my test cases, so I decided to write a few profiling methods so I can analyse what is taking the most time (the first fundamental rule of optimisation: know what to optimise). The preliminary results (executed only on a single large test case of 9 test methods) are interesting:



13% of the time is spent inferring model elements;
54% of the time is spent executing code generation;
4% of the time is spent copying previously generated (cached) code generation files;
and 29% of the time is spent actually navigating the generated application.

However, these results are affected by the code generation cache. If I only consider the first test method (i.e. there is no way to reuse previously cached information), I get a more accurate representation of the necessary time for a single test case (which does very little web application navigation):



Here we can see the initial inference time and the initial code generation time - notice they are identical (in seconds) to the overall test time.

If we remove these constant costs, we can get a picture of the average cost per test case:



12% is spent loading from cache;
11% is spent waiting for AJAX calls to return; and
70% is spent navigating around the application otherwise.

More investigation is necessary to actually see which parts of my tests I need to focus optimisation on (by profiling the entire test suite, for example).