This is useful for profiling cases where the number of Python objects is growing more than expected
Requires Python 3.14a6 and can be enabled with pstats-python-ref-tracer true
It could generate an end/start pair on a thread that is waiting due to other threads in that sync group submitting a PStats frame for the whole sync group, which would cause out-of-order events
This is more idiomatic, simplifies the code, makes it easier to port to eg. HPy later on, and makes it easier to use the limited ABI (where it can be optimized to a tail call) later on
A polyfill is provided for compatibility with Python versions 3.8 and 3.9
It changes the following things:
* Changes the counts in the PStatFrameData from uint16 to uint32, since I was hitting the value limit in some heavy frames with Python profiling enabled - no good reason for this limitation, so this allows removing it later
* Adds a T_expire_thread message, which I can use later to fix#450
These features are not used on the client side, but will be used on master. Adding these changes here now makes it possible to use a master client with a 1.10.13 version of the server (can be useful if you can't compile Panda on the host).
Otherwise any multithreaded application is dropping frames like mad, since the packets for different frames may be added to the same queue at roughly the same time.
This improves performance of PStats client when a lot of data is being sent per frame.
Also increase the value of pstats-max-queue-size, since otherwise we're constantly dropping frames when using multiple threads.
It creates a clock skew in the PStats timing information that cannot be corrected for in the server. If we want to bring this back, we should either have a global `pause()` and `resume()` (so we can properly pause collection in the meantime, and have a time to reset to, but we'd need to think about how to handle threading) or we should add a `drop_frame()` to drop the current frame. If we must bring it back in its current form, then we need to communicate the clock reset to the server, so that it can properly take it into account.
Enabled with `pstats-python-profiler 1`, requires recent version of PStats server.
Currently, it is limited to the main thread only. Support for other threads may be added at a later date.
Currently, the client doesn't send nested start/stop pairs, but there is no good reason not to handle this case in the server, and in some cases it is useful to send them (I will soon make changes on master to take advantage of this).
Client version 3.1 indicates that the client may send nested start/stop pairs.
* Windows stay open after client disconnects, for further inspection
* Ability to save session results to a file, and reopening those files
* Ability to save the current graph window layout for new sessions
* Ability to change colors (by right-clicking on bar)
* SI prefixes for Hz units (kHz, MHz, etc.)
* Ability to export session to Chrome Tracing JSON format
* "Close All Graphs" menu option
* Graphs now properly show data when opened while Pause is on
* Some fixes for weird graph window minimize behavior on Windows
Timer queries are significantly more efficient, are synchronized to CPU time, and the synchronized frame numbering makes it possible to correlate stuff in the Timeline view
- "App:Show code:General" is gone, it was causing too much trouble
- Replace odd "Client::GuiObjects" with "Nodes:GUI"
- Regroup "Dirty PipelineCyclers" underneath "PipelineCyclers"
Useful for uniquely identifying the process in a situation where multiple clients on the same host connect with the same server.
New version bump is not necessary, as old servers should just ignore the extra field in the datagram.
rdb
Disyer
kamgha
Leandro (Cerberus1746) Benedet Garcia
Sam Edwards