Roster benchmarking revisited

I was not able to leave the roster benchmarking before I was confident it could handle large rosters. Testing code in a reliable manner can be more difficult than actually producing the code itself but I found a method.

Instead of actually creating 1000 users at a jabber server, I artificially make the xml roster response with 100 users, and then just feed the very lowest parts of JabberLib for further processing. I will therefore get a very realistic situation containing everything including xml parsing, only lacking reading from network, but that is very fast. In addition, I made presence elements for 100 of these users, processed in the same way.

All test code has now been collected in a new cvs module in http://coccinella.sf.net named "tools". This module contains a lot of scripts I regularly use, such as building the coccinella execs from sources etc.

It turned out that in some situations the application seemed to freeze up, and released only after 30-60 secs. So something was hugging cpu but despite a number of timings on various parts I couldn't find it. After some struggle I found out that the sorting was done as an "after idle" command, which means it is only run once for large data sets, and here it seemed to "lock up". The problem is inside the TreeCtrl widget when I do custom sorting, since I want groups to be sorted before items. So I skip custom sorting if a directory contains more than 50 items, which seems like a reasonable balance. The bug has now been reported to http://tktreectrl.sf.net.

However, the avatar/flat roster styles must do custom sorting for the status column. This is not enabled by default but the problem remains as long as this bug is unresolved. Remember that such large roster are very rare. The bottom line is that my PowerBook G4/667MHz gives the following numbers:
benchmarking a roster with 1000 users where 100 of them are online
roster: 4571 milliseconds
presence: 2340 milliseconds
which I think is very fast on a five year old machine.

On the jdev list the so called "St Peter's roster test" is known to put clients on their knees, and I have seen numbers 1-4 minutes! Well, with a new MacTel and universal builds, I bet I could bring down those numbers under 1sec! One word of caution though: presence received just after login are handled in a simplified manner since you don't want alert sounds and all notifiers to run. So later presence is a little slower, but you wont normally get 100 of them at a time.