PStats reports Bounds using incrementing CPU time

Scripting Issues
1

It’s a weird issue, and one I didn’t know what to make of.

So I’ve programmed the same small program in C++ and Python and am comparing the two in speed. The C++ copy is proudly displaying its ridiculous speed by giving me a wall of gray representing ~16ms of wait instead of processing time on pstats; however, the Python version is doing something quite weird… as the “game” continues to execute, pstats reports incrementing time used by “Bounds”. The program starts out performing sort of close to the avg. performance of the C++ version but after about 30 seconds, I’ve gone from 60FPS to <30FPS and if you watch it go, it continues to go downhill from there (I’ve watched it go into the low 'teens but got bored after that).

So, I’m wondering, first of all, what does pstats mean by “Bounds”? My first guess was something to do with bounding boxes but after further thought I don’t think that’s totally correct.

2

Do you mean “:Bounds", that is, “Bounds” within the "” category? That is indeed the time Panda spends recomputing the automatic bounding volumes. If it’s increasing steadily, perhaps you’re leaking nodes or something like that–is the number of nodes also increasing?

David

3

Yeah, using render.analyze(), it’s showing me that I’m leaking nodes, and after a bit of looking I’ve found the problem. I was creating nodes in a looping task :laughing:… which obviously isn’t optimal. As soon as I get it cleaned up it should be working fine.

Thanks again for the help. :smiley:

4

I didn’t want to make another thread because this is related to the same program.

So I made the change and am no longer getting node leakage but the Python version is till running only at a ~66% of the speed of the C++ version and I don’t think that it’s because it’s written in Python because this time, the culprit is large sporadic Waits in the form on Thread Blocks according to PStats. I actually turned off vsync in the config.prc so the program really shouldn’t be doing much waiting, should it, as I’ve told to render the next frame as fast as bloody possible?

5

Hmm, that’s interesting. “Thread block” refers to time spent waiting for another thread (or another process) to complete. If you aren’t running any threads yourself, large amounts of “Thread block” time is usually due to the operating system scheduling other processes.

My guess is that this is due to an explicit sleep() call in ShowBase.py, which isn’t present in the C++ equivalent (or some similar difference). Try setting these variables in your Config.prc to ensure there is no redundant sleep:

client-sleep 0
multi-sleep 0
yield-timeslice 0

David

6

I did what you said and added the three vars as 0 but nothing changed. After that, I even went into ShowBase.py and commented out the setSleep() subroutine but still nothing… So, it seems that a sleep call isn’t the problem but I’m still getting these thread blocks and ONLY on the Python version… which is, as you said, very interesting.

Screenies:

7

I had something like this only when running pStats.
My problem was solved by either running pStats on a separate computer or limiting pStats rate in the config.prc:

pstats-max-rate 30

You might try an even lower value. If you get the same performance when not running pStats this is probably not helpful.

8

Hey, that actually fixed it. Python version is still running slightly slower than C++ but at least I’m not getting those thread blocks.

So, onto another question: Is it possible to export the data that PStats obtains? As, is it possible to output the graphs, the data or perhaps even obtain a min/max/avg frame value from it? Or would I just have to code that myself in the program?

9

You can run the program text-stats instead of pstats, and route the output to a file.

David

10

I tried routing it with (text-stats > “filename.txt”) but that didn’t work, because I’m guessing that only works with command line commands and cannot capture the output of applications.

11

Yes, you should do that from the command shell.

David

12

Not sure if you meant try it in the DEBUG environment command shell so I did and I tried it in the regular command prompt as well but only got an empty text file for the output.

13

Ah, sorry, the default output of text-stats goes to stderr, which doesn’t get redirected by the simple > operator by default.

Use:

text-stats >c:\file.txt 2>&1

to capture stderr as well as stdout.

David