Quote:
Originally Posted by sorrow
There hasn't been a lot of performance tuning as yet, correctness is still the priority.
I understand this completely, of course. Since you have been very ambitious about the variety of games the software is to support, correctness is obviously the first consideration.
But since I happen to multi-table full-ring NLHE, I decided to see if I could get it to work (with surprising results).
Quote:
Originally Posted by steffen123
Haven't really looked into performance at all since it's fine for the needs of myself and the other devs. For keeping the position inside a file, sorrow is reworking fpdb_import right now so it's probably best to wait for that to come to the main tree before you start implementing this. But as he noted, the biggest gains can probably be made in HudCache generation (fpdb_simple.py). Since the vast majority of CPU is spent in MySQL it might also help to play with the MySQL options, or try PGSQL as backend. Another thing that I suspect will bring a notable benefit is if there were a way to get the ID of a new row without having to run a SELECT.
Obviously performance starts to become a consideration once one has more than, say, ten HUDs running simultaneously.
I ended up stripping the code down quite drastically in the attempt to make it run as smoothly as possible. I removed the tool-tips and the pop-up window from the statistics windows, as I can happily cope without them. This, among other things, makes my code unsuitable for general use.
I also noticed that MySQL accounted for a lot of the load on the processor, and tried tampering with the database code as well. Whether this ultimately had a beneficial effect, I am not sure. As I have mentioned, I make the automatic importer wait two minutes between updates: this keeps the workload under control.
Quote:
Originally Posted by Eratosthenes
Yeah, this is the part of the cascading/stacked tables support that worries me. The code that detects when a new table is on top has to be fast and reliable to prevent the stats belonging to the previous table from staying on the screen too long. Hiding one set of stats and showing another will be quick and easy if we get the new window detection bit right.
Stranger--What operating system are you using?
I’m using Linux.
At one point I wondered how automatic detection of the currently active table could be achieved, and a cursory investigation suggested that it should be possible in X-Windows using python-xlib. Unfortunately, the variety of situations to be accounted for involving the possibility of partially overlapping tables (which might or might not obscure each others’ HUDs) is daunting. We want stack-like behaviour when the tables obscure one another, and the existing behaviour (all HUDs visible) otherwise. I have nothing useful to suggest on this topic at the moment.