debugger inspect initial performance

0 favourites
  • 7 posts
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • Ashley , i noticed that the debugger can give a wrong impression about the performance,

    to clarify,

    while inspect is active (starts at system) the most intensive actions the cpu is doing is updating the debugger itself

    if it has to update lets say 200object, = 200+ debugger fields, it drains nearly 40% of my cpu

    if i switch to profile its max 6%-7% (actually watch with not fields has the most accurate cpu usage 5%)

    if i switch to an specific object to inspect, the cpu go's to 8% (it updates only this fields)

    then inspect>system again, its + 34%

    i think that inspect (system) updates all fields of the objecttree, but it should only update the system screen.

    + a state save of what your doing would also be good> saving inspect/watch or profile

  • It only updates what it's displaying. However the browser may have to do a lot of redraw and re-layout if lots of values are changing, so it can take up lots of CPU. It's kind of normal in all software development that the debugger adds a fair amount of overhead itself.

  • yes but in case of system(selection), to me it looks like its updating much more than the rest (inspecting an object for example) maybe its because its the root of list ? , there's really no other way it would bump up the processor usage that much just by changing my selection in the inspector, nothing else is changing in my project..

  • Ashley and anyone who wants to test, wanted to know if you experience the same big difference in cpu usage


    (168 stable version)

    if i run this testfile in debugger (inspect), it shows me about 22% cpu usage, pretty heavy you would think

    if i then swith to watch or profile, it runs at 0 to 2%

    if i go to inspect - sprites - #0 it runs at 6% (notice there are more fields updating than on systempage)

    if i go to inspect - system - its back at 22%

    i still think that system overview (debugger default) is running something more then just its own page, why else so much difference?

  • Inspect in debugger is not indicative of your final performance (it even lags my PC), you run it with profile or watch and thats the realistic indicator.

    For me since I make mobile games, I aim to have my games not use more than ~15% of my i5-3570K, which results in very good performance on a wide range of devices.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • , i know its not indicative... thats the point, there's not reason the debugger should run a heavier process "on default" compared to other modes, if every mode runs its own subpage, the performance should be more or less equel, thats why i would like to compare,

    so are you saying you have same experience that inspect runs heavy on system page?

  • I was using r163 and the debugger on its default inspect view would clog my CPU at around 45% and the game was stuttery. If i switch it to Profile or Watch mode, it comes down to 15-16%.

    Also, I just then updated to r168 stable release and the debugger in inspect view suddenly work really smooth down to 15-16%.

    But, on Profile/Watch mode, my game drop down to 12-13%.. so it looks like a 20% performance gains from r163 -> r168! Great job Scirra.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)