Pokertracker load time

[Blarg]

[ QUOTE ]
Look Blarg, you're the one who thinks you know how to "tweak" XP better than Microsoft's best kernel engineers yet can't make a machine browse the web acceptably with 512MB of RAM. You're the one who thinks that demand paging (an integral feature of every modern OS since the Burroughs 6500, notice) is something to be avoided. You're the one who thinks that "commit charge" is a measurement of NT's allocated virtual address space. You're the one who claims that being a gamer adds to your authority. In short, why should we believe anything you say?


[/ QUOTE ]

What the hell are you talking about? You're the second person in the space of a few posts who has me confused with somebody else, this time over a different matter.

GET SOME BETTER READING COMPREHENSION.

I never said anything about my "tweaking" XP at all , much less doing it better than Microsoft. I didn't say anything about anything you commended on in your post.

For goodness sake, please respond to the person who is actually saying something when you criticize what they're saying. You're ascribing a whole post worth of things to me that I never said.

[Blarg]

[ QUOTE ]
This thread looks like it got pretty sidetracked from the original subject, but I'll post something along those lines anyway. For those of you who use Auto Import when playing on Party/skins (nearly everyone I imagine), does pokertracker get bogged down when importing hands? What I mean is, when I click on Pokertracker or a gametime window, it doesn't instantly pop up, the program seizes up a bit as it imports hands. Anyone have any suggestions for fixing this?

My computer's fast enough to handle something like Pokertracker without delays, I'm wondering if there's something I'm missing. Maybe it's just time to defrag.



[/ QUOTE ]

Yes. My Party tables can slog down and sometimes I can time out, when the importation of hands begins. Usually I don't, but very often I am quite close. The cursor is delayed for many seconds at a time, so moving from one table to another becomes a matter of planning ahead. The instant there's a gap in time, I start moving my mouse to the next table before the cursor is needed there, so I can be near by a button to click bet/fold/call/raise when necessary.

Additionally, windows on the taskbar can pop up slowly.

This is with 1 gig of RAM and a 7200 HD that is more than half empty, and serves me well in FPS and RTS and RPG games, etc.

I'm going to be trying to get a new computer soon, probably a 2.8 or 3.0 P4 cpu, again with a gig of ram and a 7200 rpm HD. I'm curious how much better a faster cpu will make things.

[Blarg]

[ QUOTE ]
I agree with Richard. Defragging is something done a few times a year at best, daily defragging is just overkill.

You have defragging as a common placebo right up there with rebooting, the only difference is that the latter actually helps sometimes.

[/ QUOTE ]

I've found that the difference in performance you get defragging depends upon what you use your computer for. For some games, files are read and written constantly. I've found that the RPG and RTS games I've typically run have been slowed down quite noticeably once my HD gets fragmented more than 7% or so, and very noticeably when it gets fragmented 10% or more. Playability can plunge precipitously at these levels, and spiral downwards rapidly.

Of course, these programs can stress computers a lot. And players of these games can have their HD's fragment fast because of all the writes and the considerable number of patches that some games put out. Games like Everquest and RTS's can patch at an incredible rate, constantly adding and deleting files and changing file sizes, and when you actually play the game, that sort of thing just continues for hours on end. Even if little else on your computer gets terribly fragmented, game files can get written and deleted and changed so many times in just a week or two that games really bog noticeably down if you don't pay much attention to fragmentation.

For most people, they can operate their computers for vastly longer without really feeling the effect of fragmentation. It depends very much on what you use your computer for.

[astroglide]

get a 74g raptor

[Richard Berg]

[ QUOTE ]
tivos are recording 24/7

[/ QUOTE ]
Video capture and playback is sequential (which is why they can get away with using 4200rpm drives). Defragging involves moving the heads back & forth hundreds of times a second. Hence the more apt comparison to servers -- stick an ordinary 1yr warranty Maxtor in one of Google's boxes and see how long it lasts. Longer than the doom-sayers seem to think, to be sure, but not as long as its expected life in a desktop would be either.

[Richard Berg]

[ QUOTE ]
What the hell are you talking about?

[/ QUOTE ]
Sorry. I normally only read 2+2 a couple times a week, so I still suck confusing similar names. Regardless of who's claiming what, though, there's still a ton of misinformation...

[Richard Berg]

Please guys, don't try to sound like you're conducting a scientific process when you're not.

[ QUOTE ]
look at the 'commit charge' section and note the 'peak' number. if it is less than the 'total' number under 'physical memory' you are completely running out of ram, and it is using your (infinitely slower) hard drive as a substitute when it overflows.

[/ QUOTE ]
False. You understand NT's virtual memory subsystem about as deeply as edrugtrader does EV [img]/images/graemlins/wink.gif[/img]

"commit charge" = the total size of all processes' VM + the virtual paged pool + misc system components. Basically, it's useless when diagnosing the memory crunch at issue. FYI, a better measurement of total VM usage can be found in PerfMon -> Process -> Total -> VirtualByteCounter. As you can see -- this number will be several or dozens of GB -- no sane PC can have enough RAM to eliminate virtual memory, as if that were a good idea at all.

What we care about, were we to actually determine PT's needs, are completely differnet metrics: the size of its working dataset, its frequency patterns, the distribution of its pagefault latencies, any cache-exploitable locality, and so on. Impossible to say without attaching a debugger, and probably not definitively even then. We're winning poker players here; unless you're running a 440TX chipset or something, just add some RAM already and see what happens.

My last word on fragmentation, promise: if astro reports that PT creates a fragging mess on large DBs, I reiterate my suggestion to put it on its own drive. Barring that, here's a link to the [free] tool I hinted at earlier.

[astroglide]

tivos don't use 4200rpm drives. servers have constant random i/o, and a regular defrag usually clocks in the low single digits of minutes. google actually uses maxtor ide hard drives.

[astroglide]

quoth task manager: Memory allocated to programs and the operating system. Because of memory copied to the paging file, called virtual memory, the value listed under Peak may exceed the maximum physical memory. the total is the total amount presently in use. the peak is the peak amount that has been used since the system was started. if the peak exceeds the amount of physical memory, it means virtual memory has been used. it also means this can be prevented by adding more physical memory. this is the most common method of diagnosis.

[ QUOTE ]
FYI, a better measurement of total VM usage can be found in PerfMon -> Process -> Total -> VirtualByteCounter.

[/ QUOTE ]

quoth perfmon: "Virtual Bytes is the current size, in bytes, of the virtual address space the process is using. Use of virtual address space does not necessarily imply corresponding use of either disk or main memory pages." it measures both committed and reserved space (including shared pages), and makes no distinction between them. reserved space, which is unused physically, is absolutely meaningless in this context. i can understand how you came to your position on related issues due to this misunderstanding.

[ QUOTE ]
As you can see -- this number will be several or dozens of GB -- no sane PC can have enough RAM to eliminate virtual memory, as if that were a good idea at all.

[/ QUOTE ]

when you say eliminating virtual memory, i assume you mean disabling the page file. executables and memory-mapped files will still technically page with it off but it's still a totally different scenario from the old standard of not having enough ram and using a hard drive to deal with it. i have a sane pc with 1gb of memory, and i have been using it (as well as all of my other xp systems with adequate memory) for years with the page file completely disabled. they added the feature with windows xp (before that completely disabling it was not possible); sane pcs began to reach the point where they had enough ram to eliminate the paging file. 1gb is presently enough for most users to do this with no negative effects.

[ QUOTE ]
What we care about, were we to actually determine PT's needs, are completely differnet metrics: the size of its working dataset, its frequency patterns, the distribution of its pagefault latencies, any cache-exploitable locality, and so on. Impossible to say without attaching a debugger, and probably not definitively even then.

[/ QUOTE ]

that would be cared about if we were the developers, and we were looking at how to optimize it. as users, we can only throw more horsepower to compensate for inefficiencies. one can profile the process in perfmon and see where the bottlenecks of operation are. from the simple task manager analysis, it is known that he'd be better off with some more memory for all-around better performance. i maintain that his cpu and hard drive are the primary culprits in pt's sluggishness where he described it.