Create multiple functions with the same name, say f1 = new Function("return 1;") f2 = new Function("return 2;") And call them lots of times. Both functions will be called anonymous, and will get the same entry in the profiler.
The title is wrong, if you have two functions with the same name they will not get the same entry in the profiler. Two anonymous function functions will, because they don't have any line number information or other data to distinguish them. This would be fixed if we fix https://bugs.webkit.org/show_bug.cgi?id=19229
Why don't we have line numbers? I guess the reason is more specific. If the anonymous function is made with new Function() it seems. Because we do the right things for: f1 = function() { return 1; } f2 = function() { return 2; }
I suspect that the profiler should be comparing sourceId (or whatever that property is) because eval("function(){1}") and eval("function(){2}") will both have the same line number, and url (eg. no url) --Oliver
It's dependent on what information is available at the time of execution. Previously filename and line number were not known. Can we know the sourceId at execution time?
Do we not provide such info? we do for exceptions and the debugger, so the info is actually available to us.
*** Bug 25175 has been marked as a duplicate of this bug. ***
Created attachment 50934 [details] sample named/unnamed and source/eval functions for debugging/profiling I had put this sample together to submit a new bug regarding lack of source information provided to the profiler, but then found this bug, so thought I'd just paste it on here, since it seems relevant enough. What it basically shows is that using the latest bits available (including displayName property on Functions to name them, and //@sourceURL= to name eval()'d chunks), the profiler still doesn't provide the source information for eval()'d functions. But the debugger does. One of my users has requested that the //@sourceURL bit be supported for profiling as well as debugging.
<rdar://problem/19281484>
Is this an issue with the new sampling profiler?
(In reply to comment #9) > Is this an issue with the new sampling profiler? I'm not sure. I will look into it.
This works as expected in WebKit now with the attached test case.