PokerDaVinci January BETA: semi-public release

[jukofyork]

[ QUOTE ]
PokerDaVinci has higher system requirements that an app like PokerTracker. We use a real database system (Microsoft SQL Server) and .NET 1.1 as a platform. Don't expect to run it on a 7 year old laptop and be happy with the results. You are going to probably want a screen of at least 1024x768, a decent processor and 256MB+ of RAM. It requires Windows 2000, XP or Vista.

[/ QUOTE ]

Just one question:

If you were to benchmark your product on say importing and using 1 million hands or more, then how does your product compare to Poker Tracker, Poker Office and Poker Manager.

So far I found Poker Manager wins hands down in respect to this question: it is about 3-4 times faster for import than either Poker Tracker or Poker Office <u>AND</u> DB performance does not seem to degrade badly as more hands get imported [as in other products]). Extra functionality is not helpful to me, if speed issues make a product totally unusable... [img]/images/graemlins/smile.gif[/img]

The only reason I ask this is because I don't want to waste yet another 2/3 days importing hands only to find it is not what I am looking for. For me personally the DB speed is the main factor and some kind of standard benchmark would help me most in judging which product is best [img]/images/graemlins/smile.gif[/img]

Juk [img]/images/graemlins/smile.gif[/img]

[mittelhauser]

[ QUOTE ]

Just one question:

If you were to benchmark your product on say importing and using 1 million hands or more, then how does your product compare to Poker Tracker, Poker Office and Poker Manager.

So far I found Poker Manager wins hands down in respect to this question: it is about 3-4 times faster for import than either Poker Tracker or Poker Office <u>AND</u> DB performance does not seem to degrade badly as more hands get imported [as in other products]). Extra functionality is not helpful to me, if speed issues make a product totally unusable... [img]/images/graemlins/smile.gif[/img]

The only reason I ask this is because I don't want to waste yet another 2/3 days importing hands only to find it is not what I am looking for. For me personally the DB speed is the main factor and some kind of standard benchmark would help me most in judging which product is best [img]/images/graemlins/smile.gif[/img]

Juk [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]

Juk,

I hear you. I can't give you concrete answers because I haven't taken the time to run the comps on the beta since it keeps changing. I wouldn't suggest spending 2-3 days importing a million hands into the beta since you may need to do it again w/ the February beta, etc. until the DB format is finalized for release.

Having said that, I can tell you some general "truths"...

1) The performance will be independent of the size of the file you are importing. I have no idea what the heck PT does to make it so bad when you import a large file (it seems to get exponentially worse as the file gets larger). We actually save each hand to the DB as it gets parsed so the performance is linear "O(N)" if that means anything to you. There are some bugs in the current beta which makes this statement (slightly) untrue but the next beta will resolve them. Specifically, while parsing is linear, we do things like count the number of hands in a file before we start (to provide a status bar) and this takes a *long* time if the file gets big. I need to add a method to estimate rather than count if the size of the file is big (e.g. hundreds of thousands of hands).

2) The app is entriely multi-threaded and the DB import (e.g. parsing) is separate from the viewing of the data. In other words, unlike PT which locks up the whole app (and often the whole machine with a 95% processor usage), you can simply start to import your hands and then put it into the background while you start to view your data (or do other things). This also means that it will take advantage of things like a dual processor machine.

3) Last time I checked, PokerDaVinci was about 2-3 times faster than PT for small files. There is no real comparison on larger files since (as you mention), PT just goes completely to hell. I have not tested against PokerManager. Again, this isn't an "official" comparision. That will need to wait until we get closer to release but I wanted to give you an idea.

4) Finally, the beta database is not optimized for performance so it will only get better. Although this is mostly true for the queries as we build more complex indexes. The actual parsing performance probably won't change that fundamentally since it is bound by the speed of the regular expression matching.

-Jon

[jukofyork]

Thanks for the detailed answer! [img]/images/graemlins/smile.gif[/img]

I think I better wait until the Feb beta to try importing my hands (I done this for PG SQL and PM now, and it eats a few days each time... [img]/images/graemlins/smile.gif[/img] ).

[ QUOTE ]
I have no idea what the heck PT does to make it so bad when you import a large file (it seems to get exponentially worse as the file gets larger). We actually save each hand to the DB as it gets parsed so the performance is linear "O(N)" if that means anything to you.

[/ QUOTE ]

Yep, O(n) means something to me [img]/images/graemlins/smile.gif[/img] I too have no idea what the heck PT does, but it drove me crazy in the end... [img]/images/graemlins/smile.gif[/img]

[ QUOTE ]
The app is entriely multi-threaded and the DB import (e.g. parsing) is separate from the viewing of the data. In other words, unlike PT which locks up the whole app (and often the whole machine with a 95% processor usage), you can simply start to import your hands and then put it into the background while you start to view your data (or do other things). This also means that it will take advantage of things like a dual processor machine.

[/ QUOTE ]

I too have suffered from the 'lockups'. I originally re-imported all my hands into PT/PGSQL on a separate dual processor machine (it just crashed on my machine... [img]/images/graemlins/frown.gif[/img] ). It locked the whole PC for nearly 3 days for about 900k hands, used huge amount of page-file (GBs), and used just 1 processor (PG SQL barely used 5% of 2nd processor...).

I will look forward to seeing how PokerDaVinci turns out - Juk [img]/images/graemlins/smile.gif[/img]

[mittelhauser]

Juk,

Just a quick update (both good and bad). The good first...

I have spent a fair amount of time working on the performance of PokerDaVinci after your question (profilers are your friend!). In terms of parsing performance, I have been able to speed up the base performance and fix the issues to ensure that it is basically O(n) now. I just ran a test where I imported 250k PokerStars hand histories. In round numbers, it takes around a minute/1000 hands of history. This was true at the start and at the end (the last 120k took 2h10min). My memory use also remains fairly constant (although the DB memory footprint grows agressively depending upon your settings).

The bad? First off, I have spent so much time on performance testing (which is slow) that I have neglected the core code and I am needing to push the next release back. My new release target is March 15th.

Second, I store a LOT more data about each hand than something like PT does. This means that the DB gets larger. Now that I am doing more extensive performance testing, I have a better feel for it. My 250k hands means a 1GB database file. The current DB I install (MS SQL 2000 Desktop edition) limits you to 2GB which would mean ~500k hands. There are a lot of solutions to this but they will all take some work (for either me or the user)...One option is to just upgrade to SQL Express 2005 which raises the limit to 4GB which would give approx a million hands of history. Another option is to support PostgreSQL in addition (or instead) of MSSQL since it has no limit. Obviously if the user has access to a full licensed version of MSSQL, they can use that instead with no limitations.

-Jon

[starvs]

I installed it and I am currently importing 40kish hands. I've been importing for roughly 15 minutes and im 25% of the way done. Not sure how this compares to PT, as I've never imported a large amount of hands to PT.

[Josh.]

[ QUOTE ]
I installed it and I am currently importing 40kish hands. I've been importing for roughly 15 minutes and im 25% of the way done. Not sure how this compares to PT, as I've never imported a large amount of hands to PT.

[/ QUOTE ]


i think that's comparable, though maybe a little slower (for my computer at least)

[starvs]

[ QUOTE ]
[ QUOTE ]
I installed it and I am currently importing 40kish hands. I've been importing for roughly 15 minutes and im 25% of the way done. Not sure how this compares to PT, as I've never imported a large amount of hands to PT.

[/ QUOTE ]


i think that's comparable, though maybe a little slower (for my computer at least)

[/ QUOTE ]

For refrence my computer is a 3 ghz P4C with 512 ram. I did forget to mention something that may be very important, I am importing from an external drive (USB 2.0). This may (or may not?) greatly affect the speed.

[Nibster]

[ QUOTE ]

Second, I store a LOT more data about each hand than something like PT does. This means that the DB gets larger. Now that I am doing more extensive performance testing, I have a better feel for it. My 250k hands means a 1GB database file.

[/ QUOTE ]

That seems like a lot of space for 250,000 hands. I think with datamining that would be too much, but since datamining will be non-existent for most users you may get lucky. 1 gb still seems like a ton of space for that many hands. I haven't looked at the database, but are you duplicating the data in different tables? When I look at the HH half of it is just the names of the players. I would have thought with a good data model, once you get the names of the players in the DB the amount of space used would be rather small for each HH. But, I haven't dug into it like you have so I'm probably wrong.

[mittelhauser]

Guys,

A few comments...

1) The performance issues that Juk and I were discussing is in the NEXT beta. The January beta has some bugs that slow it down as the files get larger. Please feel free to try out the January beta (with smaller numbers of hands) and give me your feedback but these are only betas. The database schema is still changing, the product is still improving...

2) Josh, I acknowledge everything you say. Pat has done a great job with PT and provides very good support which has given him a loyal following. Having said that, it is a very big (potential) market and I believe that I will be able to compete. There is plenty of space for more than one piece of software. As Xiphoid dug up, this isn't my first software venture. [img]/images/graemlins/smile.gif[/img] If I produce something substantially better and do a good job marketing it, it will succeed. If not, PT will continue to dominate and he may adopt some of the features that I have that he is missing. Either way, you (the consumer) wins.

3) Juk, I haven't had a chance to play with PokerManager much yet. How big is your firebird DB with 800k hands? Does it store info about *every* player or just players that match a certain criteria (e.g. X hands known).

4) Nibster, no there is no duplicate data in the database. However, there is a lot of calculated data. I'm at home right now so can't give you the exact stats on the various table sizes but...With 250k hands, we have:

*250k rows in the Game table (datetime, name of game, etc)
*250k rows in the GameCalc table (number of players, number of players seeing flop, total pot, rake, etc),
*I'd think somewhere between 5k and 20k rows in the Player table (this one is small and just stores their name)
* Approximately 1.5million rows in the Seat table (6 players ave * 250k hands) which stores the seat #, pos relative to button, etc.
* Approx. 1.5 million rows in the SeatCalc table. This is the BIG one where I store a lot more data than PT does. All the basic info you expect (net for the hand, player VP$IP yes/no, player went to showdown, etc). In addition to the info that they store, I keep track of more specific poker info like the rank of the hand you have at the flop, turn and river; how many overcards you have to the board at the flop and turn; how many outs you had to a straight, flush or straight flush; your EV (if more than one set of hole cards is know) at each stage, etc.

I have some ideas on how to optimize this latter data down but it becomes a tradeoff between space and performance. I can easily shrink the DB size but then the query performance may suffer to much. I am still trying to find the right balance.

One easy way to shrink the DB may be to purge out players who we don't have enough info about to be useful on a semi-regular basis. On my current test, I have 250k hands of data on one player but there are a TON of players in the DB with less than 100 hands of data on. That data could be purged, archived to a separate db (in case I get more data later), etc, etc.

Anyway, I'm still working on it...keep tuned if you are interested. Although my blog and PDV forums will be updated more than 2+2...

-Jon