Search Feedback

148
votes

Unity3D profiler must profiler multithreaded code as well

Profiling & Optimization

-

-

Since, as developers, we can rely only on the tools Unity provides to debug and profile, it's very important that these tools are actually comprehensive of the basic necessary functions.
Unity profile cannot profile multithreaded functions, making awkward to understand what's wrong some times.
If a multithreaded routine "spikes" the spike is actually shown in the profiler, but the code shown by the profiler is NOT what spikes, but just the code that is running, in that specific moment, on the MainThread, making profiling of multithreaded code, impossible.

Comments (4)

  1. Fe1036839d9e38f93391bc8729b30a53?d=mm

    blue-mile

    Nov 21, 2017 11:13

    Hi KIM-RIBER,
    Do you have any updates on this 4 months after ?

  2. 277039b40041d74887489b6e0f861f18?d=mm

    Kim-Riber

    Jul 26, 2017 11:57

    This is being worked on at the moment. We have a new implementation of the profiler backend, that has a much smaller memory footprint, better performance, and will be able to profile user threads and show them in the timeline profiler. We will release it in an experimental build, to gather feedback, before we add it to the regular release

  3. 9f534a9e5ad91593c3a446a8415d3bbc?d=mm

    andywood

    Oct 14, 2016 15:37

    Being able to profile other threads is absolutely fundamental for a development environment that would consider itself professional grade. It wouldn't be quite so crippling if there was at least a free profiler available somewhere that could do this, but I'm not finding anything.

  4. 7cda9714ec9f33b97a795ef10861cb3b?d=mm

    Arkade

    Aug 18, 2016 17:29

    I believe what the original author alludes to is that if the CPU is loaded by other threads such that the Unity threads are deprived of runtime, the Profiler can notice and attribute it incorrectly. (I say 'can' because I'm not sure what would happen if the Profiler was also deprived?)

    However more of the time, the Unity threads are not really deprived. When Unity threads have no problem but our own threaded code isn't performing adequately, there is (AFAIK) no way to profile those threads. This makes Knuth's advice to only optimize once we've profiled, impossible to follow! Working around this requires either use of custom profiling (Stopwatch) or (worse) guessing! Both consume a *lot* of time.

    Please, until the Unity Profiler supports custom threads (which we'd probably be happy to register with an API or something), could you provide any suggestions of other ways we can investigate performance problems in them?

    Many thanks in advance!

Your opinion counts

Help us make things better. Share your great idea for improving Unity or vote for other people’s.

Log in to post a new idea

Categories

All

(9356)

2D

(241)

Ads

(43)

AI & Navigation

(71)

Analytics

(106)

Animation

(330)

Asset Store

(243)

Assets

(497)

Audio

(159)

Cloud Build

(102)

Collaborate

(33)

Docs & Tutorials

(203)

Editor

(2160)

Everyplay

(13)

Game Performance Reporting

(15)

General

(831)

Graphics

(791)

GUI

(373)

Input

(150)

Licensing

(77)

Networking

(163)

Physics

(349)

Platforms

(413)

Profiling & Optimization

(72)

Runtime

(164)

Scripting

(1044)

Terrain

(152)

WebGL

(134)