I have also landed https://codereview.chromium.org/1469303004/ yesterday to
get
the common DEPS to roll into chromium, waiting for a v8-roll.
https://codereview.chromium.org/988893003/diff/41/BUILD.gn
File BUILD.gn (right):
https://codereview.chromium.org/988893003/diff/41/BUILD.gn#ne
https://codereview.chromium.org/988893003/diff/320001/include/v8-platform.h
File include/v8-platform.h (right):
https://codereview.chromium.org/988893003/diff/320001/include/v8-platform.h#newcode125
include/v8-platform.h:125: * Add a trace event to the platform tracing
system.
On 2015/11/19 at 0
I think I'm missing a test case where we can distinguish trace events by
isolate (using the isolate as id?).
I forgot to mention, that part of the major changes in the last patch is to
get
rid of context_id in favor of the much more general and ExecutionContext
system
we are adding to traci
I have addressed all comments,
Major changes include:
1- removing trace-event-common.h and put it in DEPS instead
2- removing "src/v8.h" from trace-event.h, and add trace-event.cc to be
used to
GetCurrentPlatform
3- Filing a bug for the local static variable and including it in the code
as a
On 2015/08/27 13:05:52, dsinclair wrote:
On 2015/08/27 10:48:56, Yang wrote:
> On 2015/08/25 22:02:46, caseq wrote:
> >
https://codereview.chromium.org/988893003/diff/260001/include/v8-tracing.h
> > File include/v8-tracing.h (right):
> >
> >
>
https://codereview.chromium.org/988893003/diff/2
Addressed Dan's comments.
Yang, PTAL!
https://codereview.chromium.org/988893003/diff/240001/include/v8-tracing.h
File include/v8-tracing.h (right):
https://codereview.chromium.org/988893003/diff/240001/include/v8-tracing.h#newcode32
include/v8-tracing.h:32: // These values must be in sync with
dsinclair, PTAL.
https://codereview.chromium.org/988893003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving em
On 2015/08/05 19:01:26, dsinclair wrote:
On 2015/07/08 16:44:25, fmeawad wrote:
> On 2015/07/08 09:53:04, caseq wrote:
> > +1 to getting this done (and willing to help if needed, as I had a
somewhat
> > similar CL before yurys@ kindly pointed me here).
> >
> > We wou
On 2015/07/08 09:53:04, caseq wrote:
+1 to getting this done (and willing to help if needed, as I had a
somewhat
similar CL before yurys@ kindly pointed me here).
We would like to start relying on trace events emitted by v8 in DevTools'
Timeline (in particular, crbug.com/508005 depends on th
On 2015/03/18 18:26:58, jochen (OOO) wrote:
> Nat and I had a couple of discussions yesterday,
> I will write up a doc and share it with everyone on this bug as well as
the
tracing team.
> Questions I have, is thread to isolate relation always one-to-one?
in renderer processes, yes.
> Ho
On 2015/03/18 08:56:16, yurys wrote:
On 2015/03/17 11:07:00, nduca wrote:
> Hmm! I think this is actually an interesting use case to get right, if
> possible...
>
> I'm open to storing an isolate id or "world id" on every trace event
that
comes
> in from v8 or blink. For instance, we could add
Hi Yang,
Thank you for your quick review.
I have fixed the isolate issue. The event-tracer implementation was
intended to
be very temporary as I was trying to simplify a 3-repo (V8/Blink/Chromium)
change. But I found that it might not be needed. After this CL lands, the
chromium change will g
Reviewers: Yang,
Message:
PTAL.
Description:
Implement tracing interface for v8
This is based on the Skia Implementation.
More on the project can be found here:
https://docs.google.com/a/chromium.org/document/d/1_4LAnInOB8tM_DLjptWiszRwa4qwiSsDzMkO4tU-Qes/edit#heading=h.p97rw6yt8o2j
The V8 Tr
PTAL.
https://codereview.chromium.org/607503004/diff/80001/src/array.js
File src/array.js (right):
https://codereview.chromium.org/607503004/diff/80001/src/array.js#newcode386
src/array.js:386: if (IS_NUMBER(e)) return %_NumberToString(e);
On 2014/09/30 14:49:52, fmeawad-cr wrote:
On 2014/09
I was able to observe the 30% improvement, but not the 10x improvement
you
wrote
about later. Is there something I'm missing?
Have you switched the "new Array(...).join('')" to "[...].join('')"
PTAL.
https://codereview.chromium.org/607503004/diff/80001/src/array.js
File src/array.js (rig
PTAL.
https://codereview.chromium.org/607503004/diff/60001/src/array.js
File src/array.js (right):
https://codereview.chromium.org/607503004/diff/60001/src/array.js#newcode383
src/array.js:383: var e = array[0];
On 2014/09/29 22:09:42, arv wrote:
Maybe:
if (length === 1) return TO_STRING_IN
Minor calculations error
['Do Something ' + i].join(''); 4.424 0.444 (-89.91%)
[42].join(''); 4.6 0.377 (-91.81%)
['a', 'b'].join('');0.368 0.359 (-1.03%)
https://codereview.chromium.org/607503004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
htt
Thanks arv@ for the extra test cases.
I moved the added fast path below the FastOneByteArrayJoin
Once we make the Join call, we incur a high overhead, so any branch check
overhead added by this patch is undetectable from noise.
As follow are the numbers without then with the patch
['Do Something
On 2014/09/26 00:52:34, fmeawad-cr wrote:
A micro-benchmark that motivates adding the fast path is
for (var j = 0; j < 10; j++){
for(var i = 0; i < 100; i++) {
new Array('Do Something ' + i).join('');
}
}
where a consistent 30% speedup is observed.
https://codereview.chromium.org/607503004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
Reviewers: Yang,
Message:
PTAL.
Description:
Add a fast case for one-element string arrays in ArrayJoin
This case handles CONS_ONE_BYTE_STRING_TYPE as well as Two Byte strings.
BUG=
Please review this at https://codereview.chromium.org/607503004/
SVN Base: https://v8.googlecode.com/svn/branc
On 2014/07/16 07:13:39, fmeawad-cr wrote:
On 2014/07/11 13:59:08, Yang wrote:
> On 2014/07/11 10:44:49, Yang wrote:
>
> I'm not entirely happy about this though. The filter of events is in
V8. But
I
> would argue that it should be the embedder who filters out event
On 2014/07/11 13:59:08, Yang wrote:
On 2014/07/11 10:44:49, Yang wrote:
I'm not entirely happy about this though. The filter of events is in V8.
But I
would argue that it should be the embedder who filters out events that
are not
interesting. To do that, I would have to export the list of
Reviewers: Yang,
Message:
After the addition of the IcMiss timer events, the buffers gets filed rather
quickly, and the logs becomes un-proccessable for many websites and
benchmarks.
Attempting to allow to log but exclude the IcMisses, feel free to suggest a
different approach.
Description:
On 2014/03/07 18:33:49, I haz the power (commit-bot) wrote:
No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer or
a lowly provisional committer, _not_ a full super star committer.
See http://www.chromium.org/ge
Issues addressed.
PTAL.
https://codereview.chromium.org/186163002/diff/120001/src/v8.cc
File src/v8.cc (right):
https://codereview.chromium.org/186163002/diff/120001/src/v8.cc#newcode54
src/v8.cc:54: static void empty_log_internal_events(const char* name,
int se) { return; }
On 2014/03/06 12:05
Thank you for your prompt review.
I have addressed the issues you mentioned.
Up to patch 5, I have addressed the issues without moving the V8
implementation
to a callback.
Patch 6 moves the V8 implementation to a default callback.
PTAL.
https://codereview.chromium.org/186163002/diff/60001/
Reviewers: Yang,
Message:
To enhance the embedder profiling information, I have created a callback
that
reports most of what was reported by "--log-timer-events" except for the
External events.
PTAL.
Description:
Add support for allowing an embedder to get the V8 profile timer event logs.
BU
28 matches
Mail list logo
