I'm looking at the Network and Performance tabs in Chrome Dev Tools.
The goal is to explain the reason for the gap that I see in the waterfall between the 3 seconds and the 5 seconds marks.
Looking at the Performance tab I see that most of the time is spent waiting for the Main thread (the long trailing grey lines).
Where should I look further to explain why it is spending so much time waiting?
If I select that long grey line and look at the call stack I see a lot of purple.
Does this mean that the Main thread is waiting for rendering?
Is rendering done in the Main thread?
Related
My React app does not have a mem leak, it has remained open for weeks with a steady mem consumption.
However, when let in the background or if I lock my windows session for a couple of days, the memory builds up quite a bit.
It gets back to normal quickly when I bring it back in the foreground though.
I very much suspect some rendering that gets queued, but not sure how to put my finger on the exact detail.
How can I analyze the issue in a structured way?
I am using Chrome to run a page and it runs fine for hours on end, I can attest that no memory problems rise up when it's running by itself. Whenever I use DevTools to debug something, however, the tab's memory footprint only keeps increasing and increasing (as if there was a memory leak) to the point it just crashes when it reaches the point where Chrome kills a tab due to memory limit.
Some things I could figure out were that it happens if and only if DevTools panel is open (regardless of any options?), and it happens on pretty much any website (websites that load more stuff to memory tend to bloat faster). I also found out that, if the DevTools tab is closed, the memory usage sharply drops to normal usage (something like from 900mb to 200mb, which is what it would be without DevTools), and reopening makes the tab start to bloat again from scratch. I tried running the garbage collector forcibly on Performance tab, but it also didn't do anything. I don't know what causes this, but I also couldn't find anything that refers to this issue.
Any help in this matter is appreciated.
I'm using the Profiles tab in the Chrome developer tools to record memory heap snapshots. My app has a memory leak, so I'm expecting the snapshots to gradually increase in size, which they do. But for reasons I don't understand, the first snapshot is always artificially large... creating a seemingly deceptive drop in memory between the first and second. All subsequent snapshots gradually increase as expected.
I know there is often extra memory used at the beginning of a page load, due to caching and other setup. But the same thing happens no matter when I take the first snapshot. It could be 30 seconds after the page is loaded or 30 minutes. Same pattern. My only guess is that the profile tool its self is interacting with the memory somehow, but that seems like a stretch.
Any ideas what's going on here?
Right before memory snapshot is taken Chrome tries to collect the garbage. It doesn't collect it thoroughly though, it only does a predefined number of passes (this magic number seems to be 7). Therefore, when the first snapshot is taken there still might be some uncollected garbage left.
Before making a first snapshot try going to the "Timeline" tab and forcing garbage collection manually.
From what I've tested, this always reduces the size of the first snapshot.
I have developed a voice recording app using WasApi for Windows Phone 8. But users are facing battery problem a lot and also the screen is not getting timeout while the recording is on.
And if users press the lock button on background recording is getting paused. Can anyone tell me how to solve these issues?
I am unaware of a way to turn off the screen while recording, or of a way to record while the application is in the background. That does not mean it's not possible, only that I don't know how. It may not be possible now, but become possible in the future. Other answers may explain how to do this.
So I'll list ways to reduce battery consumption while your application is running in the foreground and the screen is on:
Black display. Bright images require a lot more power than dark ones. Depending on the display technology, black pixels require a lot less power than dark pixels. Look at the Lumia Glance feature which can be always on and still requires days to drain the battery.
No animations. Depending on the display technology, redrawing the screen may require more power. In any case, calculating the animation to be drawn on the screen prevents the CPU from sleeping. Having an animation that only updates every second instead of every 15 milliseconds should already be a big improvement.
No wait loops/busy wait. If the CPU needs to wait for something don't use this pattern:
while (true)
{
if (arewethereyet())
break;
}
Cluster work into batches. The CPU needs to be able to sleep and ideally it needs to be able to sleep for long continuous periods of time. Use a long buffer duration for the microphone and don't fetch the buffer too aggressively.
Getting this exception randomly in my 3D game (using libgdx nightly build from 2014-01-03). Sometimes none for days, sometimes 5 times in 10 minutes. Almost never happens on emulator. Haven't found any reproducible scenario for weeks now, can happen even when I'm not touching the tablet at all. (I had a feeling that moving the camera or touching the screen causes this with higher probability but couldn't prove it.) Usually happens when a long worker thread (computer 'thinking', continuous rendering is turned off during this) is finished and some of the models are being repositioned to show the results.
Happens always on the same model instance consisting of 100 nodes (each node is a textured box created by six rect() calls). Some nodes may be in a short animation. I'm not requesting an iterator anywhere in my own code, I walk through the nodes with a normal for() loop because their number is fixed.
Any suggestions on how to start investigating this are appreciated. The only clue I might have that when I had the above boxes as 100 different model instances, the exception occurred somewhat less frequently. Today I merged them into one large model and already got the exception 10 times.
E/AndroidRuntime(30999): com.badlogic.gdx.utils.GdxRuntimeException: #iterator() cannot be used nested.
E/AndroidRuntime(30999): at com.badlogic.gdx.utils.Array$ArrayIterator.hasNext(Array.java:487)
E/AndroidRuntime(30999): at com.badlogic.gdx.graphics.g3d.ModelInstance.getRenderables(ModelInstance.java:356)
E/AndroidRuntime(30999): at com.badlogic.gdx.graphics.g3d.ModelInstance.getRenderables(ModelInstance.java:328)
E/AndroidRuntime(30999): at com.badlogic.gdx.graphics.g3d.ModelBatch.render(ModelBatch.java:281)
E/AndroidRuntime(30999): at com.badlogic.gdx.graphics.g3d.ModelBatch.render(ModelBatch.java:296)
It seems it was a threading problem. Most of my models are manipulated via AnimationController, but there was one place where a direct move was issued from another thread:
modelInstanceTiles.nodes.get(nodeIndex).translation.set(pos);
modelInstanceTiles.nodes.get(nodeIndex).rotation.set(rot);
modelInstanceTiles.calculateTransforms();
I have changed this to a very fast animation and no exception for 3 days now.