PDA

View Full Version : [0.38] Debugger extremely slow?



Krizzie
February 3rd, 2011, 18:12
I've been playing a few games lately and after an hour of play the game randomly freezes or crashes back to the desktop, (Vista X64) with the message that DKFX has stopped responding.

So I wanted to use the debug version to see if I could find out why the game suddenly freezes/crashes without warning.

Now I know that the debug version is a little slower cause of al the extra data that is generated, and I was used to that in the older versions. But now the game is so slow that it's no fun to play an hour to see if it crashes again. Has something been changed to the debug version that it's so incredibly slow now? My PC should be able to handle it easily (C2Q, 4GB ram, WD Raptors in RAID0)



Also another point, in other topics people mentioned this as well, the "things" limit seems to be reached a lot faster than in previous versions. I was playing Korros Tor (Second level from the DD levels) the other day and was not spamming traps or anything (neither was the AI) and in battle no one seemed to do anything. I lured all the hero's to blue's base, I usually do this and it never went wrong before with the game not rendering stuff.

Ogre
February 3rd, 2011, 18:15
Note that "keeperfx_dbg.exe" requires a lot more CPU than
standard version, and may be slow even on new computers.
Also, the generated LOG file may be very large, and after
a few hours of play it will have several hundreds megabytes.
This is why you should use standard "keeperfx.exe" if you're
not planning reporting any errors.

You should only run keeperfx_dbg if you want more detail on whats going on with the crashes and what not. You have to check the log file for the desired ERROR

Krizzie
February 3rd, 2011, 18:26
As I said I know it runs not as smooth as the normal version does, but it's unplayable now. It runs at maybe half the speed as the normal version.

I have used it in older versions (till 0.37) and it ran fine even after more than an hour play. Hence my question if something has been changed in 0.38

Metal Gear Rex
February 3rd, 2011, 18:35
I've been playing a few games lately and after an hour of play the game randomly freezes or crashes back to the desktop, (Vista X64) with the message that DKFX has stopped responding.

So I wanted to use the debug version to see if I could find out why the game suddenly freezes/crashes without warning.

Now I know that the debug version is a little slower cause of al the extra data that is generated, and I was used to that in the older versions. But now the game is so slow that it's no fun to play an hour to see if it crashes again. Has something been changed to the debug version that it's so incredibly slow now? My PC should be able to handle it easily (C2Q, 4GB ram, WD Raptors in RAID0)

I do remember another thread talking about lag and stuff. Perhaps this is the same error, the only difference is that it is MUCH slower due to the fact that it is the debug version.


Also another point, in other topics people mentioned this as well, the "things" limit seems to be reached a lot faster than in previous versions. I was playing Korros Tor (Second level from the DD levels) the other day and was not spamming traps or anything (neither was the AI) and in battle no one seemed to do anything. I lured all the hero's to blue's base, I usually do this and it never went wrong before with the game not rendering stuff.

What's the point of reporting a bug if you know its already been reported? Twice?

Krizzie
February 3rd, 2011, 18:53
It's not lag it just runs crap. Way slower than in the older versions. My hardware hasn't changed so something in the debugger is.



As for the "things" bug, it was just a side note..

Ogre
February 3rd, 2011, 19:21
But... Why are you running the debug version all the time?? :S If i dont misunderstood you. You do only need it if you can't find a error in the log... Makes not much sense otherwhise to run it ALL the time.

Metal Gear Rex
February 3rd, 2011, 19:22
But... Why are you running the debug version all the time?? :S If i dont misunderstood you. You do only need it if you can't find a error in the log... Makes not much sense otherwhise to run it ALL the time.


I've been playing a few games lately and after an hour of play the game randomly freezes or crashes back to the desktop, (Vista X64) with the message that DKFX has stopped responding.

So I wanted to use the debug version to see if I could find out why the game suddenly freezes/crashes without warning.

P_Hansson
February 3rd, 2011, 19:41
It may be that the debug version was compiled for a higher debug level this time, and that this causes more pressure on log file (and by extension your hard drive). I'm sure Mefisto can say whether this is the case or not.

If you're able to, you could check out 0.38 from SVN (see /tags sub directory) and compile with a lower debug level to filter out the less relevant messages that end up taking lots of space and processing power - then again, it's not a trivial procedure unless you already have installed and know how to use the necessary software (MingW and SVN client).

Krizzie
February 3rd, 2011, 20:34
That goes a little too far for me unfortunately. :(

If it's the log file that's slowing things down, maybe it is possible to build it so that that it only logs 100 lines of code and cleans up each time. So the file wont be huge. I mean the crashes usually occur at the end (or around the end) of the log file so the last 100 lines would be sufficient do they not?

P_Hansson
February 3rd, 2011, 21:43
Hmm, that is a good idea. However, a problem is that each time a message is to be printed, the file must be updated, if it is to contain the last 100 lines. Updating 100 lines instead of appending 1 line (for which there is a special file access mode) is actually going to be even less efficient from a processing perspective, although it's obviously going to demand much less space.

I may try to implement something like that for a "crash trace debug"-executable, but for 10 lines or less. Or even a single line, in which case it will be very easy to implement, though trying to figure out what has happened from 1 line may not be possible in all cases.

Krizzie
February 3rd, 2011, 22:03
Well Mefisto usually wanted the last 15 lines when a crash or bug occured, so 25 should be more than enough. It would surely cost less HDD space and write time (which makes the PC slow usually) I'll doubt it that DKFX can cause a 100% CPU load on modern systems. If it does than that's a possible bug too I guess.

Edit:

Ok, I just ran the Debug version with the Taskmanager on the other screen (gotta love 2!) it does pull 100% cpu (well 1 of 4) so that can also cause the lack in performance. The memory doesn't go beyond 34MB. So I think a bug snuck in somewhere compared to the older versions. A 14 year old game that can get a Core 2 Quad on it's knees surely has a bug somewhere. :P

P_Hansson
February 3rd, 2011, 22:57
Single-threaded games usually end up taking 100% of a core, simply because it isn't possible to make them "sleep" with reliability. Multi-tasking operating systems can't make any hard guarantees on the timing, and thus the Sleep() function in Windows is more suitable to GUI applications where 100 ms of randomness before resuming a background task may not matter. Thus, the game loop runs the entire time (even if doing no real work), causing 100% CPU usage. So 100% CPU is normal and doesn't say much I'm afraid.

Krizzie
February 4th, 2011, 09:06
Yes I know that part, but there's a difference between 100% load and +/-100% load. One runs fine the other makes the whole system look like an old lady. When playing a game, you should see the load varying between 90% and 100% if it just sticks at a 100% it will cause the problem. Working till the limit is fine, working at the limit isn't.

And it still doesn't explain why the debugger from the older versions ran smoother than the one now. I could even use framskip back then and it still ran smooth. After an hour it started to feel a little slow (cause of the huge log file I guess) but not at the start.

Edit:

I played the normal version with the Taskmanager on, and the cpu load was around 10% instead of 25% (100% load on 1 core) so the normal version doesn't put max pressure on the cpu.