Go abarth! Here's a couple of considerations:
1) For now, we've been concentrating on moving the remaining bits of
the V8 bindings and project files upstream. Your proposed refactoring
will more than likely involve modifying .gyp files. Perhaps it would
be better to wait just a bit more until I
I'd like to understand what's going to happen with SunSpider in the future.
Here is a set of questions and criticisms. I'm interested in how these can
be addressed.
There are 3 areas I'd like to see improved in
SunSpider, some of which we've discussed before:
#1: SunSpider is currently version
Thanks for the insights.
I stepped through the worker constructor code. The problem was at the very
last line, where we create a JS wrapper object around the core
WebCore::Worker object:
return asObject(toJS(exec, worker.release()));
Before I changed Worker.idl to have Worker derive from the
On Sat, Jul 4, 2009 at 11:47 AM, Mike Belshe m...@belshe.com wrote:
#3: The SunSpider harness has a variance problem due to CPU power savings
modes.
This one worries me because it decreases the consistency/reproducibility of
test scores and makes it harder to compare engines or to track one
On Jul 4, 2009, at 11:52 AM, Drew Wilson wrote:
1) I don't ever actually want a raw JSAbstractWorker to be created -
is there a way to disable the toJS() generation? It looks like maybe
CustomToJS might've let me do this, but it still defines toJS() in
the AbstractWorker.h file. I'd
On Jul 4, 2009, at 11:47 AM, Mike Belshe wrote:
I'd like to understand what's going to happen with SunSpider in the
future. Here is a set of questions and criticisms. I'm interested
in how these can be addressed.
There are 3 areas I'd like to see improved in SunSpider, some of
which
On Jul 4, 2009, at 1:06 PM, Peter Kasting wrote:
On Sat, Jul 4, 2009 at 11:47 AM, Mike Belshe m...@belshe.com wrote:
#3: The SunSpider harness has a variance problem due to CPU power
savings modes.
This one worries me because it decreases the consistency/
reproducibility of test scores
On Sat, Jul 4, 2009 at 10:21 AM, Dimitri Glazkovdglaz...@chromium.org wrote:
1) For now, we've been concentrating on moving the remaining bits of
the V8 bindings and project files upstream. Your proposed refactoring
will more than likely involve modifying .gyp files. Perhaps it would
be better
On Jul 4, 2009, at 8:20 PM, Adam Barth wrote:
Thanks for taking on this! I am going to try and visit SFO next week,
so perhaps we could meet up and do some strategery about this
refactoring.
I should be able to come into the SF office for a day or two this
week. That might be an efficient
FYI, we've also another WorkerContextExecutionProxy that acts like V8Proxy
in order to talk to V8 engine for everything needed in WorkerContext. When
we do refactoring for V8Proxy, we also need to make it be able to support
different execution context.
On Fri, Jul 3, 2009 at 12:23 PM, Adam Barth
10 matches
Mail list logo
