Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[Official] Profiler Improvements

Discussion in 'Editor & General Support' started by Erik-Juhl, May 17, 2016.

  1. Erik-Juhl

    Erik-Juhl

    Unity Technologies

    Joined:
    Jul 11, 2012
    Posts:
    59
    Hello!



    As you have probably seen in other threads, we like to check in on the direction we are taking with our technology to make sure we are best serving you. In this thread we would like to discuss the direction of the Profiler with you. I’d like to start by listening to what you all have experienced and what you all are needing. Knowing a bit about you also helps us better understand your feedback so please consider the following questions to get this discussion going.



    Who are you?


    What kind of game are you trying to build or would like to build?


    How does the Profiler fit into that? What use-cases do you have?


    What are the GOOD things about the Profiler that you like?


    What are the BAD things about the Profiler that you dislike?


    How can we make it BETTER?



    Thanks!

    Erik
     
    Xarbrough and Shushustorm like this.
  2. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,562
    Yay, i go first!

    * Who am i ?
    I'm Lior Tal, I'm a Unity team lead at Moon Active. We are making casual mobile games (the current and previous titles were made using Unity). You can check out Coin Master and Wonderball Heroes if you like :)

    * What games i'm making ?
    We're currently working on adding more features to Coin Master, but i do have my own passion for other game types (PC/console) that i'll perhaps do one day as a side-project.

    * How does the Profiler fit into that? What use-cases do you have?
    Coming from "standard" software development roles, profiling is an important process for me, that i try to perform on a regular basis throughout various development stages.
    Since we're on mobile, it is crucial for us to understand what causes slowdowns or why isn't the game running optimally on devices.

    Our games are 2d, and do not rely on physics or complex audio features; as such, these are the most common use cases for me:
    1. Find out the root cause for "hiccups" in the game - frames that take too long to complete and cause the game to get "stuck" for a brief moment. This can be at random times in the game, or during scene loads, where we want to find out what exactly was it that caused the slowdown.

    2. What's taking up memory - what objects are currently loaded into memory, and why ?

    3. What's the current number of draw calls - especially important on mobile, and doubly so on low-end devices.

    * What are the GOOD things about the Profiler that you like?
    Please note that all of these things come with a big "but..." at the end (listed in the next section).

    - When in "deep profiling" mode, it's ***mostly*** pretty easy to get answers to the use cases i described above. I say mostly, since it's far from being perfect (see next section).

    - The profiler allows capturing "snapshots" of memory at a particular point and browse the objects that are loaded. Super useful... this is a very common profiler feature (most C# profilers do that with managed objects).

    - Can profile mobile devices to get the performance characteristics of the real target device.

    - Not strictly profiler, but the frame debugger was a great addition to the tools we have as developers.

    * What are the BAD things about the Profiler that you dislike?
    ...brace yourselves... (sorry)

    1. When dealing with a real game (and not a test project), the profiler UI gets messy pretty quickly. It's impossible to drill down into the very last call in the CPU view for example. Also its gets slowed down to a halt (the editor literally freezes).

    2. Unless i'm doing "deep profiling" in the editor, the results are utterly useless for me. I am not 100% confident what is the exact difference between the two, but in normal mode (not deep), i can never figure out what's going on. This is the actual mode that runs on target devices, so most of the times, profiling on a device doesn't help much, and i must rely on incorrect editor results, which brings me to...

    3. Incorrect profiling data in editor - i know it says that some results may be wrong when profiling the editor, but it's hard to know which ones. For example - textures seem to be consuming twice (or more) memory in the editor. I already reported this as a bug before but i cant recall if it was resolved or dismissed.

    4. Slow frames are lost since they exceed the number of samples that can be captured. I know you can set a higher number but sometimes its not enough...

    5. Profiling on devices -- slow, the profiler doesn't always find the attached device, and on device its not a deep profile, so results are not very helpful most of the time.

    6. Profiling on WebGL - doesnt work for us... i know its all due to platform restrictions and all, but still...

    7. Capturing memory snapshots -- cannot compare 2 snapshots to see a diff.

    8. When capturing a memory snapshot - i get a listing of loaded objects in memory, and references to them. Unfortunately, references are cyclic (MonoBehaviour points to GameObject that points to MB, .... ) I reported this as a bug but it was said that this is per design. It makes it difficult to find the roots to assets / objects and why they are kept in memory.

    9. Can't export profiler data to file!! this is a must !!!!

    10. Profiling duration - the timeline shows around 10 seconds? why can't i profile a longer period of time ?

    11. Can't "focus" on a particular section of a profiling session (e.g: mark begin/ end like most profilers have).

    12. Search - only works when i disable the "record" button, even if profiler is off. Also, it only searches the current frame. I can't look for all occurrences of a particular method call with this search (only by scrubbing the entire profiling session until i find it).

    13. Profiler API (Profiler class) - very limited. Not sure many people actually use that (me included) since its not clear how to operate it.

    There are probably others things that elude me right now, sorry for the long list, it's just that this is a very important tool and i feel it doesn't (didn't) get the love it deserves and it must be improved.

    * How can we make it BETTER?

    1. Fix usability issues - no more slowness. Allow me to drill down into every last method call my game makes without waiting 10 seconds to expand the call.

    2. Take a look at other profiling tools (Unreal engine 4, C# profilers, etc) to get a list of common features (new views that allow viewing the data to find issues faster, diffing between snapshots, serializing snapshots, etc).

    3. Expose the data as an API so i can export it and use other tools (custom built? excel? etc) to view it offline.

    4. Better support for profiling on devices .

    Feel free to contact me in private for any other questions or comments you have on this matter!! i'm on the beta group and you can also email me (liortal53@gmail.com). I'd be more than happy to test any work-in-progress improvements you have.

    Cheers,
    Lior
     
  3. pvloon

    pvloon

    Joined:
    Oct 5, 2011
    Posts:
    591
    Very glad to see that the profiler is going to get some love!

    Who are you?
    Arthur Brussee, shader programmer currently on some of my own projects previously lead graphics dev on Ori and the blind Forest.

    What kind of game are you trying to build or would like to build?
    Referring to Ori, an open world 2D metroidvania, currently some GPU oriented frameworks and a 3D walking simulator type game.

    How does the Profiler fit into that? What use-cases do you have?
    One of my main jobs on Ori was optimising the crap out of everything. The profiler helped tons here though I used a variety of tools, mainly PIX on the Xbox One too.


    What are the GOOD things about the Profiler that you like?

    • Low friction to use, everything from in-editor profiling to auto connecting to builds etc. Super fast and easy
    • CPU AND GPU profiling in the same window, awesome.
    • The ability to profile Editor code is great! I write lots of tools in unity that need to be fast (scene view stuff, complicated inpsectors, baking tools etc.)
    • "Take Sample" in the memory profiler is awesome to look for potential leaks.

    What are the BAD things about the Profiler that you dislike?


    The single biggest thing is Performance:
    • The UI is incredibly slow and irresponsive. Deep Profile just locks up my PC pretty much when profiling Ori, it was entirely useless. Even the normal modes show up as significant OnGUI() spikes whenever the profiler window is redrawn (in Profile editor mode).
    • The overhead of having record enabled is huge. Normal record mode has enough overhead to a point of having to take all results with a grain of salt, deep profile slows any somewhat large project to an unplayable crawl.
    Other than that there are some UI annoyances, see improvements section

    How can we make it BETTER?

    • Optimize all parts related to the profiler: IMGUI, the data capture, Profiler.BeginSample, OnGUI of the profiler window etc. Seriously it's almost an order of magnitude of before the true potential of the profiler can be used, and that's a real shame. I can't stress this point enough, all of the points below this one are moot if this is not fixed as they probably can't even be implemented without making the window faster.
    • Provide some tool to analyse a window of frames and accumulate/average results. Often times one frame doesn't give enough info to see what's slowing you down, averaging results over a timespan is a very common use case for profilers. Imagine playing the game for 30 seconds and then accumulating all that data to see where power goes over a normal period of play.
    • Obviously non-development builds can't be profiled but at least some basic abilities (total frame time / GPU time) on a master build would eliminate the need for everyone to write their own hacky debug FPS counters.
    • Continue the work started here: http://forum.unity3d.com/threads/weve-started-work-on-a-new-memory-profiler.358963/ It should fill in the gaps Take Sample currently has, was sad to see it abandoned halfway
    • There might be a need to have some mode that lies between default <-> deep profiling. Deep profiling is almost too detailled digging into mono functions, C# library etc. Even with UT's best efforts the sheer amount of data will always slow the profiler down too. A mode that captures only the entire callstack for user code would help reduce the noise and more perfomant.
    Some small tid bits:
    • Implement this suggestion by Lucas Meijer: https://gist.github.com/lucasmeijer/7475fd40ff6ac34c7c44 and get rid of the 1.1Kb of garbage generated by a GetComponent<>() call. This makes it very hard to track GC in editor besides being a general waste of performance
    • Currently the window only occasionally redraws, forcing it every frame feels so much nicer and responsive.
    • Only tangentially related, but Debug.Log is so slow that if there's any of them firing off anywhere it destroys your profile. Not helpful when you're trying to profile + log some info about some code
    • Zooming in and out in the graph view.
    • Serialize the graph view state. Currently when going into playmode or recompiling you lose your place and have to search again for the item you're actually optimising currently.
    • The ability to select a hierarchy item and jump to it in C# code when relevant.
    • More stats on scene data: the ability to measure scene loading times, see what scenes are loaded / loading etc. For streamed games these stats are very important but almost not present in the profiler. Now with multi scene editing this will only get more relevant.
    • An API like:
    • Code (csharp):
      1. using(new Profiler.BeginSampleScope("Auto dispose!")) { }
    • would help clean up some code sometimes (though please don't copy the IMGUI teams mistakes and make the scope a struct, not a class....)

    Thanks for taking a look at the profiler, excited to see what's to come.
     
    dadude123, MrEsquire and hippocoder like this.
  4. dizzy2003

    dizzy2003

    Joined:
    Nov 25, 2013
    Posts:
    107
    Who are you?

    Mike Diskett

    What kind of game are you trying to build or would like to build?

    Made/Improving Satellite Reign http://store.steampowered.com/app/268870/

    How does the Profiler fit into that? What use-cases do you have?

    Looking for spots to optimise/ Mem allocs to eradicate

    What are the GOOD things about the Profiler that you like?

    Love the time line view.
    Love that it works and connects to remote stand alone builds

    What are the BAD things about the Profiler that you dislike?

    Deep profile doesnt really work because it ends up just showing you which functions call the most child functions

    How can we make it BETTER?

    Network view needs a bandwidth monitor
    I'd like to access the profile internal info at runtime to overlay my own profiler on screen (or one off the asset store)
    The memory view never works for me (crashes out, I have 10 million+ game objects)
    If It did work I'd like to snapshot 2 frames and get a diff so I can look for mem leaks
    Remove unity editor mem allocs from the Hierarchy GC Alloc column, so I dont have to profile a stand alone build to look for memory allocs
    Would Like a sampling profiler like SN tuner too
    Profiler Begin/End should work in my own multithreaded code
    Theres chunks of unity that dont show up in the profiler (may have changed recently, but movie textures, async scene load, asset loading, asset bundle decompress, asset bundle loading)
    Theres an api to load and save profile info, buttons to do this should be implemented in the profiler UI
    Combine the output from multiple frames so we can get more of an average with all the spikes smoothed out, or more of a sum of GC allocs, or see a min/max time for each item
    Dont show items as overhead, describe them explicitly (wait for sync, profiler, etc)
    Be nice to be able to right click items (in the hierarchy/timeline view) and tell that item to go one level deeper (like deep profile but not all the way down the call tree) in the samples when continuing
    Time line view as you zoom in should shows ms vertical bars

    Thanks,
    Mike
     
    forestrf likes this.
  5. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    I'll skip the parts already mentioned about the good and the bad - I agree with all that's already been stated in the thread.

    Who are you?

    Baste!
    I'm the lead gameplay programmer on World To The West here at Rain.

    What kind of game are you trying to build or would like to build?
    World To The West is a top-down 3D action adventure game. We're a mid-sized team with ~8 people that has their hands in the

    How does the Profiler fit into that? What use-cases do you have?
    We're using the profiler a ton to figure out what's causing our game to slow down when it does, and what's eating memory.

    What are the GOOD things about the Profiler that you like?
    It's really easy to use and intuitive! For all of the instances where we've found serious slowdowns this far, the profiler has helped us track down the source.

    What are the BAD things about the Profiler that you dislike?
    If you open the profiler window, and then close it, the profiler's still running, and you get the occasional "the profiler has run out of samples for this frame" error. This is a really annoying bug, and you either have to keep the profiler open with the "Record" button off, or restart Unity.

    As other people have said, the UI performance. There was a thread a while back about this, and it seems like Unity's recalculating all of the data on every GUI frame. This causes big profiler samples - in particular in Deep Profiling - to be really, really annoying to work with. You need to do some serious culling here!

    How can we make it BETTER?

    I keep seeing this forum thread be re-created: "my game's really slow, and the profiler shows that GFX.WaitForPresent is using all of my performance! How can I fix that?". You should really rename WaitForPresent, or put the message "your CPU is waiting for the GPU to finish rendering" directly into the profiler. You should also show what's causing it to happen - is it v-sync, or is it something else?

    MonoBehaviour.OnMouse_ causes 0.6kb of garbage on every frame - but only in the editor (apparently). This is confusing - either fix the garbage in the editor, or mark it as "editor only" in the Profiler so we can ignore it confidently. Since this is essentially the same issue as the GetComponent garbage, this is a vote in favor of internal hiding of the garbage.

    More information about what's causing garbage to be generated in general would also be great - if it's doable. Things like "This garbage is due to you creating an array" or "this garbage is due to instantiating and object" or "this garbage is due to our incredibly broken Mono version" would be good information to work with. I recently discovered that sending lambdas as function arguments causes boxing, and caused a bunch of extra GC work. If the GC Alloc field could have tags like [Boxing] and [Object created] or things like that, it would be easier to tell what's going on at a glance.

    Clear on Play - like the console, a clear on play feature would be nice. Then you know that all the samples you're looking at is from the latest code change.

    I'll ping @steinbitglis, he did a lot of the world on our other game, Teslagrad, and I can remember him having some issues with the Profiler as well.
     
    forestrf likes this.
  6. steinbitglis

    steinbitglis

    Joined:
    Sep 22, 2011
    Posts:
    254
    First of all: I really really appreciate that you're paying attention to this.

    Since Unity 5.0 showed up, I haven't yet felt that the stability and
    robustness of Unity has been satisfying. I this is a wonderful angle to
    take in that regard. Better debugging and better data can really speed
    the process up.

    Then I apologize that my post will have a lot of not-so-simple suggestions.

    Who are you?

    Fredrik Ludvigsen

    What kind of game are you trying to build or would like to build?
    I'm also currently working on World to the West.

    How does the Profiler fit into that? What use-cases do you have?
    All releases do, especially when optimizing memory requirements and
    framerate issues. I'm going to create console versions, where memory
    constraints often requires months and months of extra work.

    What are the GOOD things about the Profiler that you like?
    I like that the simple frametime and memory hogs are easy to find.

    What are the BAD things about the Profiler that you dislike?
    For anything else than simple functions and references that are compiled
    into public variables in MonoBehaviours, things are much harder.

    Let's say I have a static Dictionary<GameObject, Func<GameObject>>,
    this is unlikely to be handled by the profiler in any intuitive way.

    Often it's really really hard to track down why assets don't unload from memory.
    This is often related to static variables, which are just excluded from the
    memory profiler.

    How can we make it BETTER?
    Create a separate view, not tied to a timeline, where I can get a full
    overview of all the resources in the resources dependency graph (if there's such a thing).

    I want to see all the dependencies that cause resources to stay loaded.

    I have reported bugs that still don't have any explanation, and which
    have been reproduced by Unity. The problem was that some resources didn't
    unload from memory. If such a view existed, I would see
    the problem at a glance, whether the bug is ours or not.

    Then create a hierarchy-like view + inspector where I can see all
    the loaded GameObjects and scripts as if I was still in the editor.
    This view should be read-only.

    Then make it optional to also view objects that are 'HideAndDontSave'.

    With this view... it should be possible to ping the correct objects when
    digging in the detailed memory view that fails to do so in the ordinary hierarchy.
     
  7. benblo

    benblo

    Joined:
    Aug 14, 2007
    Posts:
    476
    Before I begin, I sent a bunch of feedback a few months ago (can't remember if it was to a field engineer? the UX team?), though it might be stale.

    Who are you?
    Benoit Fouletier, tech/tool programmer at Swing Swing Submarine.

    What kind of game are you trying to build or would like to build?
    Seasons after Fall, 2D platformer focused on exploration, in a big streaming world (hopefully), with lush visuals and gigatons of textures.

    How does the Profiler fit into that? What use-cases do you have?
    In that order, with #1 way above the others:
    1. hunting down spikes, trying to figure out what happens when and why loading stuff takes time (and more importantly, why it spikes).
    2. hunting GC allocs
    3. improving framerate
    On our previous game (Tetrobot and Co), it was mostly about hunting leaks (memory was killing us on mobile), and GC for spikes.

    What are the GOOD things about the Profiler that you like?
    • Easy to use, all-in-one tool
    • Available straight away in editor (though I rarely use it anymore because it's so different from builds, it can be very misleading)
    • Click an item and seeing it highlighted over time is AWESOME
    • Unlike others in this thread I don't really have performance issues re the Window itself, at least not in shallow mode

    What are the BAD things about the Profiler that you dislike?
    • Profiling loading is terrible
    • Having to make a dev build is a pain. Our QA uses normal builds (because dev builds are intrusive, eg the BTW-crappy in-game console keeps popping in case of errors, etc), so if we need to profile an issue with the same changeset we never another build. I imagine the diff in only in the executable & DLLs, not the assets (?), so ideally we could make a dual build in one go. Or, alternatively make a dev build with a non-dev mode (eg no console).
    • No deep profiling on builds (or at least I could never make it work), and editor profiling is of little value.
    • Sometimes (not too frequent but still) I have difficulties hooking up to a build, restarting the editor and/or the build fixes it
    • The "Other" category and Overhead stuff is infuriating, welcome to the black box!
    • Some stuff seem to show up in the timeline but not in the main view, or not in the same color
    • Relationships between jobs in the timeline is sometimes unclear/confusing:
      • some jobs in the main thread rely on the render thread, we need dotted lines or something
      • BTW it sometimes looks like false positive, eg a job in the main thread is blamed for taking 100ms but in case it looks like it's stalled by the render thread that's finishing something else, possibly from the previous frame
      • jobs in one thread have another nested below them, but they don't have the same color category!
        upload_2016-5-18_16-1-7.png
        ... green spike in rendering, but wait it's actually a loading :( !
    • No horizontal scrollbar is ridiculous: # of frames == # of pixels!?... so I put the profiler window on my biggest monitor just so it's wider. I have to hurry out of the game and press stop record if I want to inspect something that just happened. Worse if framerate is high because the frames expire more quickly.
    • The vertical autozoom is sort of intuitive but can also be annoying, I'd like to be able to lock it to say 60 or 30 fps, to prevent it from jumping around. Can also be misleading to see the view filled with bars when in fact it just zoomed in and the max is 1ms.
    • Not a big fan of the triangul-ish frames, sometimes it's not clear which frame took a while: this one or the previous? And once you have the cursor on a frame the white line blocks everything! I'd much rather have a proper histogram with square bars (possibly with the option to space them like in GPA)
    • The frame number in the top-left corner is irrelevant (the index in the array of captured frames?), I want the in-game frame number, so I can match it with logs or whatever. Right now if you stop/resume record, or even restart the play mode, or profile a different build, the view doesn't even show a whitespace or anything to separate the sessions, and the frame numbers stay consecutive :(.
    • V-sync category is broken for me, so I spend my time staring at a block of green:
      upload_2016-5-18_15-57-48.png
      So... rendering is taking 15ms, really? oh wait, it's all "Gfx.WaitForPresent"... not very useful.
    How can we make it BETTER?
    Usability:
    • Fix the UI issues I mentioned: frame # == ingame frame #, horizontal scrollbar, vertical zoom, histogram instead of triangles
    • If frame width stays constant, I'd like to have a time grid behind the main view, with lines every 0.x seconds (the more the lines are compressed, the more you're lagging)
    • I love that we can see prev/next frame jobs in timeline view, but then I want to click them to skip to prev/next frame.
    • Option to show both the hierarchy and timeline at once
    • Small items get grouped together in the timeline view until they're totally unusable, I want to double-click a group and zoom on its contents, or see the list of jobs inside somewhere.
    • Save/load profiles, ideally compare 2 profiles
    Filtering filtering filtering!
    • It's very hard to focus on something precise.
      • If I uncheck a category in the main view, give my an option to also remove it from the hierarchy/timeline
      • Right-click a root node -> hide
      • I want to white-list stuff: say I have a system that's a known quantity, maybe it uses a lot of ms/GC but it's been optimized already, so just filter it out (in the histogram and hierarchy and timeline) so I can better focus/zoom on the rest.
    • It's very hard to have an "average" view of stuff: eg I want to see how much time loading a bundle took, how much fps was used during the life of a particle FX, how much GC a system allocates over time, not on a particular frame.
    I'm just dreaming here:
    • Better relationship between game events and time/frames: I wanna be able to issue events/tags/labels ("start loading bundle", "finish level load & spawn player"), and see lines or blocks in the main view. Then I make a change, replay the same segment, and can compare a previous profile in-between the same events.
    • Dedicated "Loading" view, with multi-frame events, like profiling the load of a web page
      • I'd also love to have this in editor: some of our scenes take close to a minute to load, it's impossible to tell why and what to do about it.
    • Dedicated GC view: see what's allocated, over time. Also I'd LOVE to be able to see not what is allocated, but what is collected, so when I have a GC spike I can see the content "how look it's mostly stuff allocated by script X since the last collect".
    • Custom filtering/queries: select a range of frames, run an SQL query to filter only what I need, compute averages, etc
    • Simulate build in editor: so the delta between editor and build is too high, how about we try to reduce it? Allow the editor to enter a "mock build" state, where you strip away all you can (compile without UNITY_EDITOR, remove gizmos, the GetComponent() ghost, don't call OnValidate or any of the editor callbacks, etc etc).
      On Seasons after Fall we compile everything to DLLs, so we actually do this, for the compilation part. It's super useful to run runtime codepaths in-editor, and sometimes spot issues without needing to make a build. But unfortunately it doesn't change the difference between how the editor handles resources, profiling overhead, etc etc.
     
    Cromfeli likes this.
  8. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    I'm going to second the histogram suggestion - the triangles are really hard to read. A histogram would be a straight up improvement.

    The vertical scroll is also a great suggestion - give us a soft or hard cap on how many frames we want to save instead of having it be dependent on window width.

    In general, great suggestions, but those two stood out to me as obvious.
     
  9. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    -The overview panel... it doesn't just have a horizontal scrollbar.. and the none of the columns can be resized to be small enough to full make the 'Overview' column large enough to just actually see the full code path length most of the time.. yeh you can select the row and look at the top to see the fullname, or disable column to make more room, or resize the profile window and everything else in the ui (EVERYTIME) but guess what a horizontal scrollbar allows for guys, much quicker, yeh they get a little ugly and take up like 20px height.. but sometimes that's ok when your UI is designed in such a rigid way.

    -Another sucky area, you cannot just move the the CPU Usage/Rendering/Memory etc.. rows into a visual order that is preferable to making the best use of screenspace with less vertical scrolling.. ie If you just want to see CPU/Rending/Physix/Networking... together..

    -CPU Usage, all the of subitems can be enable/disable.. whatever happened to adding the same functionality to the rest of it.. like Rendering etc.. It's probably overlooked and not really used, because disabling individual graph items, doesn't let you resize anything to take less vertical space anyway..its all fixed sized..And no Zooming in/out on the graph .. while its not a huge deal its mainly about the numbers on the frame timeline anyway, the profiler for me is more just an overview of everything.. because as I've seen mentioned above, it lacks really giving you much detailed info... like what specific things are taking up memory... For something that isn't providing a lot of useful detail, it sure does take up alot ui space to get the most out of it.

    -And compared to other game engines (Unreal/Cry), the total lack of a built in developer console, with built in commands to change values on the fly.... and built in hud to show values, and graphs is just effing annoying, making you have to rely on having the Profiler tab opened up somewhere..and totally useless for builds...unless you build and improve all that stuff yourself and go blow money at the asset store trying out half a dozen half finished implementation of something that should just be built in properly!

    Saving out a profile log, and loading them back into a profiler window...obviously with ways to set what gets logged or not, and in how much detail, I don't need all that info.. and if I can chuck out portions of it to gain larger timeline view the better.

    Allow using code to invoke the profiler to start logging to file, pause, stop etc maybe get fancy and allow inserting visual marks on the timeline at key triggered events (like if its already logging).. so that saved profiler logs make more sense. Anything along those lines would also be a huge help to compare changes on performance between iterations and unity version.... while you're at sort out the unity video codecs, build in way to record the game/scene to save a capture along with the profile data, that way profiled scenes can have video data to go with it..

    The good things about the Profiler is it does work, I'd be interested in seeing any improvements.

    And while on this.. as I don't see you guys opening another thread on the Project window..

    -Add a details view with columns that at least show file Sizes, and Date/Time for created/modified.
    -Make the a list view that actually show thumbnails at a reasonable size 24-64x.. instead of just the file icons, which for textures/3dmodels is annoying.... that silly scrollbar at the bottom of the project folder sits on list view permanently.. because the thumbnail views goto the crappy grid view.. where sure you get to see actual thumbnail views.. but then you barely see any filenames unless the thumbnails are giant size.. silly really

    -Add a unique Asset folder that is ignores everything in it like script files from being compiled.. I often try out assets or find plugins that are dead weight to my project, and sometimes just want to disable them.. Short of going in and moving them out the project in a file manager, there is no direct easy way to disable entire assets folder (like having different folder icon color for a disable folder), or specific scripts... or disabling the entire folder from being compiled and run... it just gets annoying dealing with this..I literally have a folder in the root project folder next to assets folder.. where I move editor scripts/plugin folders I don't want to use at the time.. Why not just implement a feature for disabling script/folder execution directly in the editor.


    And lasty the make the editor meta file data store a lastKnownFilename, so I don't have to see the stupid Missing Script stuff in components from broken store assets scenes or broken unity upgrades etc.. When it could just display the last know filename.. instead of missing script.

    fileFormatVersion: 999
    guid: 999999999999999999999999999
    lastKnownFilename: SHTDEMOSCRIPT.cs <HOPEFULLY NEVER HAVE TO SEE 'MISSING SCRIPT' WHERE THE EDITOR CANNOT EVEN GIVE ME A CLUE WITH A HUMAN READABLE FILENAME.
    folderAsset: yes
    timeCreated: 9999999999
    licenseType: Free
    DefaultImporter:
    userData:
    assetBundleName:
    assetBundleVariant:
     
  10. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,589
    Fix these bugs:
    (Case 745488) Profiler window is unresponsive
    (Case 704398) Cannot turn off Profiler
     
  11. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Hi @Erik Juhl

    Rob Cummings of Simian Squared

    Open world 3rd Person game for PS4.

    The profiler is used to track down whatever is slow, so I can fix that.

    Sort by time ms. I love this. I can also sort by GC alloc and so on.

    It doesn't really give much richness to the data, and it still bugs out (enable it, use it, stop using it, and it still does errrors like profiler ran out of samples :/) also limited.

    1. double click something in profiler to take me to the code or object in Unity scene...

    2. much richer graphics reporting. Want to know, fine grained, what objects are taking longer to render, maybe some shader profiling...... would be godlike.

    3. It'd be kinda nice to make snapshots so I can compare the latest run vs a snapshot, maybe with fancy graph. Are my efforts making a measurable impact? Perhaps export a frame from the profiler with fancy graphs/html data.
     
  12. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    9,350
    Just some random wish/idea list,

    Cloud Profiler(tm)
    - Profile your game in all most common devices (without having to buy them yourself)
    - Profiler history (compare stats with older builds or with different device, and see the whole history, so can see if things are getting better or not)
    - Profiling device groups: If you want to publish into Chinese market, you want to test mainly on those devices
    - Remote Cloud Profiling, if you want to go deeper with certain device, you could remotely profile on it yourself
    - Main benefits: No need to buy all the devices, Profiling is in the cloud (you can keep working while its going on), whole history of stats if saved (easy to compare and see progress)


    But anyways maybe give scripting/api access to extend the unity profiler (unless there already is?),
    so can make tools for saving reports, doing comparison tools and more..
     
  13. Brian-Kehrer

    Brian-Kehrer

    Joined:
    Nov 7, 2006
    Posts:
    411
    I'm Brian - Graphics programmer, game developer, VR developer.

    I'm currently working on mobile VR, as well as a PC / PS4 title.

    Diagnosing framerate issues, alloc, etc.

    Couldn't work without the profiler. It's generally excellent.

    Nothing to complain about - the one thing I find hard to diagnose is a 'sawtooth' pattern. Whenever the profiler starts doing the sawtooth thing, I cringe. In my work, this seems to usually be GPU bandwidth related, but I've seen other causes as well, such as multithreaded functionality. Getting more precise timing / bandwidth / memory / cache info might help here. If the GPU is thrashing on bandwidth because of cache misses, I'm not sure how I should determine that. Or maybe I'm saturating the texturing units, or the interpolators, who knows?
     
  14. steinbitglis

    steinbitglis

    Joined:
    Sep 22, 2011
    Posts:
    254
  15. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,641
    Hi,

    I am Freejam CTO, developer of Robocraft. I am not going to fill out the form because I feel the previous guys have touched pretty much all the important points, however I do have a suggestion for your long term plans. If you will go for the .net core integration, consider to make at least the stand alone build compatible with all the existing .net profilers. It would be awesome for me to use the commercial profilers available.
     
  16. Cromfeli

    Cromfeli

    Joined:
    Oct 30, 2014
    Posts:
    202
    Who are you?
    Developer at startup

    What kind of game are you trying to build or would like to build?
    AR&VR apps and games

    How does the Profiler fit into that? What use-cases do you have?

    Performance optimization

    What are the GOOD things about the Profiler that you like?

    Mobile profiling

    What are the BAD things about the Profiler that you dislike?
    Inability to filter results to improve "Signal-to-Noise" ratio. Having more explicit control what is visualized and also having possibility to manually set framerate scale instead of automatic scaling (Auto scale removes important cognitive que). So in essence more control would be good to have.

    Suggestion: Can we have cumulative profiler statistics over selected period of time? E.g. how much specific operation contributed to GC over previous 100 frames or how much execution time operation Y took over previous 10 frames.

    Implementation
    : Timeline selection in profiler and then see aggregate process statistics over specific amount of frames. e.g. if I shift selected frame in profiler and then dragged the cursor over following 100 frames it would then show me the combined result over those frames.

    Use case: Now it is very discrete to see what happened each frame, but some times it would be very interesting to see performance over specific scenario, what was the cumulative most taxing operation or process that has been running. It would be easier to discriminate and optimize operations that look innocent but actually contribute greatly over longer period of time.
     
    poshaughnessey likes this.
  17. hangar

    hangar

    Joined:
    Feb 1, 2013
    Posts:
    21
    Sorry I'm late to the party. Hopefully you're still watching this thread.

    Who are you?


    Greg Nagel, Free Range Games


    What kind of game are you trying to build or would like to build?


    We're all over the map. Mostly desktop, mobile, some console, web. Big project right now is Labyrinth.


    How does the Profiler fit into that? What use-cases do you have?

    Mostly hunting down GC. Allocations cause more trouble than anything. Otherwise, performance problems, usually graphics-related, sometime scripting: what do we shave from memory on mobile, or how do we get the framerate down. I look at CPU, GPU and memory. I also end up trying to profile custom inspector work sometimes. Editor profiling tends to be harder to decipher than runtime.


    What are the GOOD things about the Profiler that you like?
    • It shows GC pretty clearly. I don't know how we'd have figured out half of our problems without that.
    • Pretty good at connecting to whatever device I'm looking at. (Though a few times it's been overeager and profiled my coworker's machine—I think you fixed that bug.)
    • It accounts for pretty much everything that goes on in a frame. While I want better filtering, you can't trust a profiler that doesn't give you access to the whole picture.

    What are the BAD things about the Profiler that you dislike?
    • +1 to everything benblo said. I have had issues will all of it, down to the triangle-shaped frames.
      • Especially profiling loading. That cannot be overstated. You've done so much to help improve load times lately, but it's easy for us to do stupid things and not have any way to determine what they are.
      • The black-box overhead is especially prevalent on consoles. Please tell us what it is, at least in broad strokes.
    • That last frame likes to hide behind the edge of the window, and it's really hard catch the right frame when you've got editor profiling on. When you're trying to profile the first few frames after a compile, it takes more than a few tries, and the UnityEngine.Profiler API doesn't work too well with editor profiling. (I am OK with editor profiling being a second-class feature though.)

    How can we make it BETTER?

    A) If we run out of samples for a frame, we really need to see those samples! Can you at least keep the samples you've already collected, and lump everything else into some "untracked" sample?

    B) All it takes is one return in the wrong place to make BeginFrame and EndFrame not match up in an incredibly hard way to detect. Or you might get an exception. It's easy enough to make foolproof with an IDisposable hack. eg: using (Profiler.Sample("Foo", obj)) { /* ... */ } (Only downside is you can't use ConditionalAttribute to compile out a method with a return value.)

    C) Profiler.BeginSample is one of the methods that I keep wishing could be called from any thread. It could be a no-op, even, though especially the allocation information would be useful.

    Side issue: There's no thread-safe way to check if you're even allowed to call the Unity API.

    D) Building on benblo's filtering: Filtering out a root node (or any hierarchy) is useful, though more often I want to filter out every node with the same name, but keep those nodes' children. (Saves a recompile, and would also make a deep profile more useful.)

    E) When you have a sample for a constructor (under Loading.ReadObject, for instance) can you also capture the cost of the object allocation? Maybe in a separate sample. The question I'm usually asking here is "how much time did I spend deserializing this type of field in a SerializedObject"?

    If you were to put samples on all C# allocations by the Unity API, you would give us a lot more information to work with.

    F) Maybe this is beyond your scope, but fixing some allocations in OnGUI would certainly go a long way to improving the profiler window's performance. One of the biggest problems I see is that pretty much every string returned by the Unity API allocates, including UnityEngine.Object.name. Caching a lot more of them (even just checking a cached string field against the C++ string for changes each time) would mitigate a number of issues.

    G) And this might be off-topic, but it'd be nice if we didn't have to use the OnGUI Rendering Statistics Gizmo for checking draw calls, etc. As with a lot of .NET stuff, this is a solved problem, and the way servers handle this is ETW, which is the chosen technology for this sort of profiling in Core CLR. Notably, System.Diagnostics.Tracing.EventSource/EventLogTraceListener provide an fast, allocation-free way to listen to events, and you hardly pay for it if you don't listen to those events. (The Core CLR version also hooks into Windows Event Reporting or Instruments, etc, but I don't know if we need that. Maybe it'd help integrate with IL2CPP profiling.)

    If you gave us per-frame info in ETW, it would let us collect statistics in whatever way we want, with our own logic. So we could collect statistics over X frames, only look at events we care about, use open source libraries to process the data, etc.

    If you gave us ETW events whenever Unity invoked C#, we could know how many update calls were happening from frame to frame or track down an unexpected usage of an [InitializeOnLoadMethod] in an otherwise opaque library. Or collect stack traces in debug for coroutines (see this).
     
    Cromfeli likes this.
  18. Shushustorm

    Shushustorm

    Joined:
    Jan 6, 2014
    Posts:
    1,084
    Who are you?
    A developer working mostly on his own.

    What kind of game are you trying to build or would like to build?
    This is very different and it depends on the concept of the game. But until recently, I have worked mostly on titles for iOS and Android.

    How does the Profiler fit into that? What use-cases do you have?
    The profiler is very important to track down performance issues, even early on in development. In my case, it generally does a pretty good job.

    What are the GOOD things about the Profiler that you like?
    It's quite easy to use and rather straightforward.

    What are the BAD things about the Profiler that you dislike?
    Sometimes, there will be some "Unaccounted" stuff going on that impacts performance and I don't know how to solve it because its source doesn't seem to be known.
    Also, either the profiler or the stat's window have an issue with actually showing the right FPS count.
    ( See http://forum.unity3d.com/threads/stats-fps-not-fitting-profiler-f2.411903/ for reference. This is still happening in the current build, F3. Unfortunately, the beta forum is locked.)

    How can we make it BETTER?
    This is why I am actually posting:
    Could you implement a feature that logs the data and shows me average values after I stop the play mode?
    This could be very useful, because sometimes the profiler will have a lot of spikes making it hard to figure out which changes influence the scene the most.
    (See http://forum.unity3d.com/threads/profiler-collect-data-averages.423982/ for reference.)
     
    Cromfeli likes this.
  19. robochase

    robochase

    Joined:
    Mar 1, 2014
    Posts:
    244
    Who are you?
    Chase de Languillette

    What kind of game are you trying to build or would like to build?
    Currently working on a multiplayer VR game.

    How does the Profiler fit into that? What use-cases do you have?
    I frequently need to use the profiler to find the root cause of frame spikes.

    What are the GOOD things about the Profiler that you like?
    A single snapshot is very detailed and quite helpful.

    What are the BAD things about the Profiler that you dislike?
    It only records 300 frames of snapshot data and then throws out data older than that. Really? hard drive space is cheap. save that stuff somewhere! this setup is completely inadequate for VR development, unfortunately.

    How can we make it BETTER?
    I need to be able to view more than 300 frames/snapshots at a time. When working in VR, 300 snapshots is nothing. It takes me that long to pull off the VR headset and pause the editor, meaning I lose the important data i'm trying to capture. yeah, i can rig up something to pause the editor from within VR, but that's a pain, and sometimes the act of pausing can ruin certain tests. i can't imagine the snapshots taking up that much hard drive space, so we should absolutely have the option to record as large of a snapshot buffer as we need. Thanks!

    before you say: hey we're adding the profiler TO vr...sure, that's a nice addition, but it would still be super valuable to be able to capture more than 300 snapshots at a time.
     
    Cromfeli likes this.
  20. pahe

    pahe

    Joined:
    May 10, 2011
    Posts:
    543
    Oh, just found this thread. Did I miss some announcement? Would be great to get some more annoucements if you create such threads (and I really appreciate that!).

    * Who am i ?
    I'm the Unity Team Lead in our Company (50-60 developers). Apart from that, I'm also developing my own Unity game, so I can say, I'm a part time hobbyist :D


    * What games i'm making ?
    Mostly mobile games in the company, but who knows. The games are mainly strategy games, more or less graphic heavy (our older titles less, the newer ones more), but we have also some action games.
    For myself, I'm targeting standalone platforms, mobile and consoles. It's a 2D point and click adventure game.

    * How does the Profiler fit into that? What use-cases do you have?
    Profiling the app helps a lot to find performance issues, memory usage, draw call issues (in case of the frame debugger. If this thread is only about the profiler, then ignore this).

    Especially on mobile, you have to manage memory a lot, check what data is loaded, when it is loaded and more importantly, when is it really unloaded. Taking memory snapshots is giving us some good info about where the memory is used and which assets (mostly textures or audio files) need better compression.

    Checking draw calls and batching is also important for us, as well as see overdraw issues.

    CPU tracking and script performance indicates for us areas where we should have a look into, although it's mostly giving only a clue, as our own scripts are pretty low weight, while engine internals (hello AwakeFromLoad) are mostly taking the most time (I come to that later again).

    We rarely touch the Audio or Network Profilers though.


    * What are the GOOD things about the Profiler that you like?
    • Profiling via USB or WiFi is pretty awesome (was unstable in the past, nowadays it's working fine) and gives us a good possibility to check what's the bottleneck on the smartphones.
    • Memory snapshots! Nice thing for sure! It sometimes lacks a bit of info (I come to that later), but the experimential memory profiler by Lucas gives some more nice info.
    • Not sure why there is a simple view for memory, we always use the detail screen which gives us some good first info where to look for memory issues.
    • Script debugging gives some first infos where to check for code performance problems.
    • Framedebugger helps identifying batching problems, but... (I come to that later).


    * What are the BAD things about the Profiler that you dislike?
    • Blackboxes! Blackboxes everywhere! I hate those! Really!!! Some examples? Sure!
      -- Who can tell me what "Overhead" means in the CPU profiler. After weeks of research, I know now, but how can I reduce it?
      -- WaitForTargetFPS?
      -- Application.Integrate Assets into Background? Loading.RemappingIDs? Loading.AwakeFromLoad?
      -- many many more....
      I've to admit that it has improved over the years, but I think you get what I mean. You have to search the forums a lot, before you know that you can't do much about it. At least some names are now giving more info what is happening (still, Overhead is my favorite :) ).
    • When we're at blackboxes, ever wondered why "SerializedFiles" take so much memory? We have, until we found out what it meant. But why use so cryptic names? What is really loaded in the ShaderLab and why does it take so much memory now? System.ExecutablesAndDlls can be found several times in the forums, everyone asking what that stands for, but there is no mentioning in the docs.
    • "Referenced by" in the current memory profiler doesn't work, right? It gives a small clue, but I think 95% of the time I try to use it, it didn't work. The experimential memory profiler did a better job there, at least for me.
    • Every had the "unable to insert branch island" problem on iOS? Don't know if Unity can do something about it, but it's... bad.
    • Another blackbox: drawcall batching. When does it work, when it doesn't? We don't know and even you can't tell all the times. I' waiting for the day my thread will be unlocked ;)
    • The detail view of the Rendering profiler is not much useful. I always think "Please switch to detail mode" only realizing that there is no. It gives an overview, but it lacks the detail information we need.
    • Debugging Assetbundles is a pain! Not sure if the Profiler could help, but that would be nice.
    • Also Shaders. Not sure when they are included in the build, when and if they are loaded.

    * How can we make it BETTER?
    • Remove the blackboxes. If there is something, the profiler can't know, tell us why (e.g. "memory is managed by OS. Not possible to evaluate by Profiler").
    • Explain some things in the docs for the Profiler if some names are clear to you, but not for us ("Overhead" means this but it's not in the official docs).
    • Give us information why batching doesn't work. Or if that is too difficult for now, mark items which are not batched, although they should (if that's easier :p).
    • Would be nice if referenced items are correct or show that the profiler can't recognize what is referenced (don't know how that can happen though).
    • Give us more information about loaded shaders, what features they are using (or which variants are loaded).
    • I'd to have more access to the Profiler API. Not sure if that is possible, but I think by opening it a bit more, we would see some extensions/tools/improvements for it.

    As mentioned, I really appreciate that you want feedback on the current tools!
     
    Last edited: Oct 7, 2016
  21. Venryx

    Venryx

    Joined:
    Sep 25, 2012
    Posts:
    444
    Who are you? / What kind of game are you trying to build or would like to build?

    Indie dev from Seattle, working on an RTS game in Unity for the last couple years.

    What are the BAD things about the Profiler that you dislike?


    The main issue for me is that the profiler has no way to "collapse" long but meaningless call-stack segments.

    This is most commonly a problem for Mono's MethodInfo.Invoke function. Whenever you call it, it has like 5 levels deep of calls to inner Invoke functions.

    In my game, I call Invoke all the time (I use reflection to find event listeners methods, and have them called automatically when the event is triggered). But because each Invoke call adds five or so call-stack entries, it takes forever to drill down in the tree! Sometimes it's literally over 30 levels of clicking till I can see what I'm actually interested in.

    This makes it useless for those call-paths, so I've had to resort to using a custom profiler system that doesn't record all those intermediate and useless "inner invoke" calls.

    How can we make it BETTER?

    One solution to the problem would be to let the user right-click a call-stack entry, and mark it as "collapse". This will cause any calls to that method (anywhere in the tree) to be collapsed -- meaning its children become direct children of its parent (perhaps with an icon to signify the collapsing and let you undo it).
     
  22. Nicolas1212

    Nicolas1212

    Joined:
    Dec 18, 2014
    Posts:
    139
    Who are you?
    Lead dev at TripleFun

    What kind of game are you trying to build or would like to build?
    Mobile 2D games

    How does the Profiler fit into that? What use-cases do you have?
    Finding out those random lag spikes, optimising everything so we can run at 60fps

    What are the GOOD things about the Profiler that you like?
    • Easy to use
    • Quick overview
    • Draw call analyser is great
    What are the BAD things about the Profiler that you dislike?
    • Limited by screen size? That's a massive negative. Save for the entire profiling session; it's up to the dev to make sure they've enough space and when to start/stop it
    • No way to average frames - is a particular call once off, or is it a frame spike. Should be able to drag a selection to sample everything inside it
    • No way to save/load profiling sessions, making judging improvements incredibly hard. I have to write the numbers down, and again, they're per frame, so which one is the right one?
    • Too many ambiguous terms in the CPU sampler - BehaviourUpdate: cool, which script? AwakeFromLoad: cool, which objects? All these Canvas calls: cool, which parts of the UI are we talking about?
    • Clicking on an item never seems to give names in the bottom right hand section - it's always been N/A for me (at least testing on a device)
    • Similarly, often times, it's missing method calls, and I have to manually add Profiler.BeginSample() calls to get actual data. Activating Deep Profiler doesn't seem to change this
    How can we make it BETTER?
    • Record forever
    • Average data (massively useful to seeing if your changes have made a difference in the long run)
    • Save/load sessions
    • A new API in Profiler, Profiler.MarkLine("Foo") or something, that draws a big vertical line in the graph - useful for dealing with states
    • Bars instead of spikes please
    • Limit or allow us to fix vertical scrolling
    • If I click to remove, say Rendering, or Physics, etc from the CPU Usage chart, allow me to remove the calls from the Hierarchy view as well (e.g. I might only care about user scripts)
    • Every term should have a description, or at least a central area where we can find out what all the names mean and common reasons why they might show up, and the ways to fix them
    • Allow us to search for a method which would then be highlighted etc
    • Should automatically remove profiler related overhead from the results
    • Allow us to trigger/stop profiling from code. This would let us get very precise comparative sessions (e.g. "the first X seconds after the player does this")
    • The ability to filter custom code from unity code (e.g. I can optimise my code, I can only optimise how I call Unity code)
    When we made Flash games, we were using Adobe Scout (https://www.adobe.com/ie/products/scout.html), which has a lot of these features and can be good to take a look at if you're looking to steal an idea or two.

    Thanks
     
    Venryx and Cromfeli like this.
  23. Wahooney

    Wahooney

    Joined:
    Mar 8, 2010
    Posts:
    281
    Who are you?
    Senior Coder, RetroEpic Software

    What kind of game are you trying to build or would like to build?
    Multiple & various (COIN, mobile cutter, digital boardgame; to name a few)

    How does the Profiler fit into that? What use-cases do you have?
    Need things to run faster (obvs :p). COIN game has a procedural level aspect that takes a lot of runtime to execute, so used the profiler alot there.

    What are the GOOD things about the Profiler that you like?
    Allows us to optimise fairly slow actions (<~300ms) with deep profiling.

    What are the BAD things about the Profiler that you dislike?
    REALLY slow functions (>1sec) aren't possible to deep profile. Profiler either runs out of samples or Unity crashes.

    How can we make it BETTER?
    Allow us to cordon off the profiler. For instance, only profile between Profiler.BeginCordon() and Profiler.EndCordon(), so we don't waste profiler samples on parts of the game that are entirely unrelated to our profiling needs, ie. I really don't need to know what the EditorUI is doing when I'm trying to profile my procedural terrain generation).
     
  24. Contato

    Contato

    Joined:
    Oct 2, 2015
    Posts:
    16
    Who are you?
    Indie programmer.

    What kind of game are you trying to build or would like to build?
    Multiplayer defense game

    How does the Profiler fit into that? What use-cases do you have?
    For understanding why sometimes I have 1000 fps and sometimes 16 fps and it is not about GC.

    What are the GOOD things about the Profiler that you like?
    The Profiler is quite good as a whole, I like the Profiler a lot except for one thing described down below.

    What are the BAD things about the Profiler that you dislike?
    I don't understand why sometimes and entry consumes 10.8% cpu, but if I use the Deep Profile and sum the subentries it shouldn't be 10.8%.
    I can't find on the internet what is NavMeshManager > WaitForJobGroup > Crowd.Corners, so I have no idea what can be done. This is very disappointing.
    Or why is Components.NavMeshAgent.TransformChangedMessage so high? If I turn IK off there is a little gain in my game.

    How can we make it BETTER?
    I lose a lot of time guessing what means what and then trying to figure out how make things better, if there is a documentation with that level of detail would be great.
     

    Attached Files:

  25. CanisLupus

    CanisLupus

    Joined:
    Jul 29, 2013
    Posts:
    427
    Who are you?
    Daniel Lobo, lead programmer at Insignio Labs.

    What kind of game are you trying to build or would like to build?
    Generally 2D games/programs for learning and social causes, both mobile and desktop. :) I have also personally created assets for the Unity Store (UnifiedIO and Seek) and other Unity things.

    How does the Profiler fit into that? What use-cases do you have?
    1. Find out why one frame is taking so long. It's common to have giant spikes when the user clicks a button and we do too many things. Especially if you are creating a sheet music editor in Unity. Trust me.
    2. Find out where the frame rate can be improved on mobile, hopefully along with battery savings.
    3. Memory usage. For mobile this is a must.

    What are the GOOD things about the Profiler that you like?

    Easy to use and visualize problems in code and memory waste. Thanks to it, we've discovered many "un-guessable" (at the time) performance problems (using Math.Abs and String.StartsWith too much were two ridiculous examples).

    What are the BAD things about the Profiler that you dislike?
    It's very very VERY slow when inspecting a frame where a lot of things happened in scripts (in Deep Profile, which I always have to use, otherwise I don't learn much). It sure seems like the Profiler window's OnGUI is causing all the values (percentages, times, sizes) to be constantly recalculated, because everything in the editor becomes extremely unresponsive. Sometimes it takes 10 seconds to expand a single stack call.
    (I created this thread about all this some time ago.)

    How can we make it BETTER?
    Cache everything about the frame when it is first selected. Once. Then just draw what you have calculated instead of slowing down everything. :)
    Also check the helpful suggestions and criticisms of folks above me who have other needs.

    Thanks for reading and asking us for feedback!
    Daniel
     
  26. daxiongmao

    daxiongmao

    Joined:
    Feb 2, 2016
    Posts:
    412
    Who are you?
    Jeremy Rose, Technical Director at Wolf team IDreamSky

    Unity 5.5.1f1

    Pretty much yes to everything everyone has said here.

    Some simple things that could be fixed it is in the normal profiler mode, not deep.
    Display the correct labels for the functions. I am seeing events from coroutines that are know are unloaded.
    Second fix the N/A in so many of the views. I have to figure out most time from the hierarchy of code calls which object its referring too instead of seeing xxx game object name.
    Some maybe fixed already possibly in 5.6?

    Well at least trying to expand a deep profile has given me time to find this forum and read it.

    Oh and I was reading some other threads and saw some responses I thought were strange.
    The unity response was because you are using deep profile that the times will be slower because of the overhead.
    And that makes sense for the game but I wasn't sure why he was giving this response to a question about the displayed results. I thought maybe he didn't understand the question or something but then i thought about it more.
    When I enable deep profiler and it does its broad hooks am I actually deep profiling the same code that is used to display the deep profiler results?

    If so then his statement doesn't seem so strange?
    Just the fact the profiler is profiling the profiler's displayed results. :)
     
    Cromfeli likes this.
  27. forestrf

    forestrf

    Joined:
    Aug 28, 2010
    Posts:
    229
    Being able to profile custom threads would be a very, very good addition
     
  28. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    241
    @Erik-Juhl: It's been over a year now that this thread was started, a lot of really great feedback from users in here, but neither any kind of reply from Unity nor any changes to the profiler. So can you maybe tell us what's happening on this end? The profiler is a *really* important part for development, especially as we still can't use regular external .NET profilers for Unity games (hint hint ;) ).


    Think the two biggest issues *we* see are:
    1. No support for background threads
    2. No documentation on the binary format of the profiler data

    Especially point 2 could maybe be addressed without a lot of work on your end and would already allow a lot more analysis of the data that's already gathered by the profiler as is.

    Regards,
    Chris
     
    Cromfeli and forestrf like this.
  29. pahe

    pahe

    Joined:
    May 10, 2011
    Posts:
    543
    @Alloc
    Well, nothing is not completely correct. There is the experimential memory profiler which gets updates from time to time. I talked a bit with some Unity guys at the Unite Europe about it and they admit that it is not the highest priority for them at the moment, the may need some poking to review pull requests, but they haven't forgotten about it and they want to improve it.

    To your 1) point: I guess they won't work on that, until they have added their own threading system. But that's just a guess by me.
     
  30. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    241
    Well, unfortunately that thing is completely useless if you don't do a mobile game but have a large PC project.
    Also, this thread is an official one from Unity, it's even stickied, still there is not a single post (other than the opening post of course ;) ) from an Unity employee.

    And I just don't get how such a decision can be made. As there's no support for any third party tools for profiling this should indeed be high priority. You can't do a big project like a full blown game and expect everything to be fine without having the most important tool for systematic optimizations at hand :(

    Hope someone from Unity can chime in on this topic :)
     
    forestrf likes this.
  31. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,589
    While I'm recently a little more active in the forums, I noticed one "issue" with the profiler window that always causes at least one additional question: Did you profile a build or in the editor?

    Thus, if someone posts a screenshot of the profiler window, it would be really useful to see whether it is profiling a build or the game running in the editor. It doesn't have to be anything fancy UI wise, just something in the Profiler window to tell whether it's profiling a build.
     
    moco2k, alexeyzakharov and forestrf like this.
  32. Xype

    Xype

    Joined:
    Apr 10, 2017
    Posts:
    339
    What would really be useful is for them to not include data from the profiler or the editor in the profiler lol....really confuses things.
     
  33. Xype

    Xype

    Joined:
    Apr 10, 2017
    Posts:
    339
    The profiler needs a lot of polishing up, it is way behind a 3rd party tool wich can also profile visual studio, can be attached to a running application to get data then detatched so you can review without overloading your running applicatin, it can do remote profiling, and they keep improving it.

    Why IDC, even though its good, because what I want is the profiler in unity to work, that with script inspector 3 = no more leaving the editor to do silly things.
     
  34. Alloc

    Alloc

    Joined:
    Jun 5, 2013
    Posts:
    241
    Are you saying you found a 3rd party profiler that's able to profile Unity games? If so, mind to share what it is? :)
     
  35. Xype

    Xype

    Joined:
    Apr 10, 2017
    Posts:
    339
    It has been around a while but they are already on top of getting it to work with unity 2017.2

    http://www.jetbrains.com/products.html?fromMenu#lang=csharp&tech=dotnet

    I was already familiar with their tools so it made jumping in this round that much easier too. Just get the ultimate subscription for it, then you can code anything c++ up in one toolset
     
  36. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,562
    I don't think this profiler is compatible with Unity (or Mono)