I have a Firebase Performance Monitoring trace called my_trace.
Now, I start this trace when I load an image:
void loadImage() {
final Trace trace = performance.newTrace("my_trace");
trace.start();
// ... (loading that happens asynchronously)
trace.stop();
}
This works fine when I try to load a single image, however, in my application I need to load many images in parallel.
This means that the following error is reported when I load my images:
Trace 'my_trace' has already started, should not start again!
How do I correctly start a trace multiple times in parallel as I want to record the performance of every single loading process?
Note: I cannot use HTTPMetric as the loading trace also contains image conversion and not just downloading.
You can record it manually by storing the start time yourself and then just recording the duration. This should work.
Reference: https://firebase.google.com/docs/reference/js/firebase.performance.Trace#record
As the error message says, there can only be a single trace with a unique name active at any time. So you'll either have to wait for the first my_trace to finish before starting the second (running them sequentially instead of in parallel), or you'll have to generate a unique name for each trace.
Given how the API is structured it should be possible to allow multiple traces of the same name to run in parallel. If you think Firebase should consider allowing that, I recommend you file a feature request.
Traces are allowed to run in parallel already. Traces are not indexed by trace names. As long the trace object is unique, you should be able to run traces in parallel. Same trace object cannot be re-used.
Eg: (Incorrect way of using trace object)
final Trace trace = performance.newTrace("my_trace");
trace.start();
trace.start(); // This would not work. Fails with the error message that the trace is already started.
// ... (loading that happens asynchronously)
trace.stop();
Eg: Right way using the same trace name multiple times in parallel.
final Trace trace1 = performance.newTrace("my_trace");
final Trace trace2 = performance.newTrace("my_trace");
trace1.start();
trace2.start();
// ... (loading that happens asynchronously)
trace1.stop();
trace2.stop();
Related
I've recently run a method tracing session on the process of opening a FragmentActivity that takes about 750-1000ms to open from the previous activity and has a ListView into which it loads its initial batch of data in times that vary from as low ("low") as 1500ms to as high as 5000ms. After sorting by "exclusive time", I noticed that a method named android.os.MessageQueue.next is taking up the plurality of the time.
A view of all the main thread after a method tracing session. Notice android.os.MessageQueue.next is first in the list:
Now, my question is as such: is this standard operating procedure in an Android app--that is, does android.os.MessageQueue.next refer to the main queue waiting for another operation? Or, alternately, could this indicate some sort of temporary deadlock?
Should I be worried?
If you are using a handler thread hopefully something went wrong. I could see these lines in source code of MessageQueue's next method. Have a look it may help you to understand.
** Message next()
{ // Return here if the message loop has already quit and been disposed. // This can happen if the application tries to restart a looper after quit // which is not supported. **
Source code
I was going through following tutorial: http://www.dreamincode.net/forums/topic/190013-creating-simple-file-chooser/#viewSource
Inside the FileChooser class there is one exception beeing supressed, since there is nothing within the catch clause. So I decided to add following statement to the catch clause:
Log.e(ACTIVITY_SERVICE, e.getCause().toString());
For some reason this always causes the app to crash (NullPointerException). When I don't do any logging, except for a a simple syso print, then I don't get any exception and the app does't crash either. Then it works fine. I'm new to the whole Android Framework and just want to understand why this is happening.
Thanks to Ingo's and CommonsWare's hints I came to the conclusion, that following line caused the exception:
EDIT:
In fact it was the start of the foreach loop, which iterates over all subdirectories and files of a given directory. I didn't know, that this would cause a NPE, if the list you want to iterate on is actually null. For some reason I thought that the loop would be automatically skipped in this case.
I am working on a flash game and about finished with it but I'm running into an issue. When the game ends, or the user presses the "End Game" button I want to return them to the main menu. The game is set up so that the main menu is on the 3rd frame, and the game runs in the 4th frame. All of the game code is there.
A few things I have tried:
I just simply tried to return to the 3rd frame. This results in the error:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at Hundred_fla::MainTimeline/GotoEndGame()[Hundred_fla.MainTimeline::frame5:66]
I have tried returning all the game vars to their default values, removing all children... so on... I also get the exact same error... not sure what the problem is. I thought one solution would be to reload the movie, but this will be running on Android/IOS and I cannot refresh a webpage. ... any help would be greatly appreciated. Thanks
Edit: The code on line 66 is:
while(stage.numChildren > 0){
stage.removeChildAt(stage.numChildren-1);
}
You should lock stage link before trying to purge it of objects. You are seemingly removing the instance that runs the code, so it loses stage reference.
var theStage:Stage=stage;
while(theStage.numChildren > 0){
theStage.removeChildAt(0);
//you can always be sure that element at [0] exists, rather than going for [numChildren-1]
}
Depending on what's line 66 of the 5th frame, it could a few things:
you are targeting Flash Player 9, where the display objects are loaded asynchronously to your gotoAndStop call, so you end up with null references. Solution is to target Flash Player 10 or 11 (change it in Publish Settings [Ctrl+Shift+F12]). If you really need to target Flash Player 9, there are convoluted methods to ensure the attributes are accessible
after the gotoAndStop you are referencing an object from the 5th frame, which is not available anymore, and thus throws a null object reference error
it's an error in your logic and we need to see some of the code to find it
When in doubt, it's always best to leave the gotoAndStop call as the last one in the method.
Edit:
After seeing the code, it seems that stage itself is null and thus throwing the error. If it makes no visible difference, you can surround your code with a try/catch:
try {
while(stage.numChildren){
stage.removeChildAt(0);
}
} catch (error:Error) {
}
Also try listening to the ADDED_TO_STAGE event to make sure you have a valid reference to stage before accessing it.
I am using Debug.startMethodTracing and Debug.stopMethodTracing to optimize a piece of code that takes about 30 sec to execute but when I open the trace file with trace view it only shows me about 6.5 secondes of trace data.
Any clues ?
The function startMethodTracing by default only logs 8MB of trace data. To get a longer trace, set the second parameter to the maximum trace size you want it to record (in bytes).
startMethodTracing("mytrace", 100000000);
The buffer is limited by the device ram. You cannot specify a too big buffer when calling Debug.startMethodTracing.
My logcat window in Eclipse only displays the first few lines of the StackTrace for each exception. This means that I often can't see where an exception occured. Is there any way to change this setting?
If you're referring to the "...12 more lines..." part, you only see that for exceptions that were the cause of another exception. If the top part of the stack trace is the same as the earlier trace, the full set of frames is only shown for the outermost exception, and the other traces get the "..." treatment.
Put another way, the chunk of a trace that isn't shown is a duplicate of a trace that appeared earlier in the exception cause chain. For example, suppose I have code where the method main() calls one(), which calls two(), and so on. four() throws an exception. two() catches it and re-throws it. The exception will look like this:
java.lang.RuntimeException: re-throw
at Foo.two(Foo.java:14)
at Foo.one(Foo.java:7)
at Foo.main(Foo.java:3)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.RuntimeException: first
at Foo.four(Foo.java:23)
at Foo.three(Foo.java:19)
at Foo.two(Foo.java:12)
... 3 more
The "caused by" exception says "... 3 more" rather than explicitly listing one(), main(), and dalvik.system.NativeStart.main. So to get the full trace of the initial exception, you would start by reading its trace, then continue at the trace above.
Note there is no overlap -- two() appears in both, but in the "first" trace it's on the call to three(), and in the "re-throw" trace it's on the throw instruction.
you can overload all the log methods (log.d, log.i, log.e, etc) with (String tag, String msg, Throwable tr) parameters, where the third parameter is the exception. This will give you the full stacktrace in logcat
http://developer.android.com/reference/android/util/Log.html
If your code calls a method which produces too tall of stack you can (and should) handle the exception in your code and output whatever is relevant to logs.
If you have no exception handling whatsoever and you don't even know where in your code should you be putting such a handler then the problem is entirely elsewhere - you should be handling exceptions a bit better than that.