Thanks! Feel free to provide any additional comments, if you will have them later.
http://codereview.chromium.org/1105009/diff/1/2 File include/v8-profiler.h (right): http://codereview.chromium.org/1105009/diff/1/2#newcode80 include/v8-profiler.h:80: * Returns the number, 1-based, of the line where the function originates. On 2010/03/23 08:25:11, Søren Gjesse wrote:
We are not consistent here, as Message::GetLineNumber() returns
1-based line
numbers whereas Function::GetScriptLineNumber() and the debugger
returns zero
based line numbers. I have bees advocating for zero based as that is
what we use
internally, but I am not so sure anymore. However we should have a
constant for
information not available as Function::kLineOffsetNotFound. Maybe
using a shared
constant for this will be the best, and -1 will fit in both schemes.
I think that as this info is for people, and editor programs they use start line numeration with 1, it's preferred to return 1-based numbers, otherwise somebody next in the chain will anyway need to add 1 to the number returned. Using a constant for "no info" is certainly a good way. http://codereview.chromium.org/1105009/diff/1/2#newcode88 include/v8-profiler.h:88: */ On 2010/03/23 08:25:11, Søren Gjesse wrote:
Should we consider using uint64_t and change to a higher resolution
than
milliseconds?
I propose doubles for easier interconnection with JavaScript, where Numbers are doubles. I think there is no need to try to achieve a better resolution, than milliseconds with a software-only (that is, not using CPU h/w counters) profiler. http://codereview.chromium.org/1105009 -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev To unsubscribe from this group, send email to v8-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
