Thanks for answering. OK, any ways I might hack on this in an unsupported
way? I wish to take the risk.
пятница, 30 октября 2015 г., 10:29:54 UTC+3 пользователь Hannes Payer
написал:
>
> Nope, that is not supported. We are continuously working on making gc
> pauses negligible.
> On Oct 30,
Nope, that is not supported. We are continuously working on making gc
pauses negligible.
On Oct 30, 2015 8:24 AM, "Artem Chivchalov" wrote:
> Hi all,
>
> I'm using node.js v5 (V8 4.6.85.25). I wonder is there any way in native
> code to explicitly disable GC runs (at least
Hi all,
I'm using node.js v5 (V8 4.6.85.25). I wonder is there any way in native
code to explicitly disable GC runs (at least mark-sweep-compact runs)
during the specified period of time, while executing some code sensitive to
delays? Something like this:
disableGc();
runCodeWithoutDelays();
I tried running demo again with OpenGL command queue, but that didn't
change runtime performance a lot. This time without typed arrays.
In profiler, the same function for binding vertex buffer still shows up as
a function that taking long time to excute, even though that JS function
does not
Is there anyway to use something like CreateDataProperty to override the
accessor so that the actual function is associated with the property,
albeit lazily created?
I tried to use CreateDataProperty in place of ForceSet, since ForceSet is
deprecated, but that didn't do it, and my property
Speaking of Really Bad Ideas: V8 flags aren't designed to be toggled
arbitrarily at runtime. I wouldn't be surprised if lots of stuff started
breaking when you mess with flags. (If I were to design an embedder, I
wouldn't even provide a "v8.setFlagsFromString()" interface, because having
one just
On Fri, Oct 30, 2015 at 9:18 AM, Artem Chivchalov wrote:
> Thanks for answering. OK, any ways I might hack on this in an unsupported
> way? I wish to take the risk.
See below, I think it's technically possible in node.js to disable
compaction at run-time but it's arguably a
On Fri, Oct 30, 2015 at 2:13 PM, Artem Chivchalov
wrote:
>
> Thanks for the --never-compact flag tip. What bad things can I expect
> using this at run-time?
>
Crashes, memory leaks, random wrong behavior. And it probably won't be
deterministic -- a quick test will look
On Fri, Oct 30, 2015 at 11:47 AM, Jakob Kummerow wrote:
> Speaking of Really Bad Ideas: V8 flags aren't designed to be toggled
> arbitrarily at runtime. I wouldn't be surprised if lots of stuff started
> breaking when you mess with flags. (If I were to design an embedder,
Thanks for the --never-compact flag tip. What bad things can I expect using
this at run-time? Also, is the compaction step the most expensive operation
of mark-sweep-compact algorithm? And how expensive is the flag switching
itself?
пятница, 30 октября 2015 г., 10:24:25 UTC+3 пользователь
If it was only a performance concern to always go through accessors, it is
now also a functionality issue for profiling. The function name in cpu
profile result shows up as "get " for the last property this
accessor function is associated to.
I tried CreateDataProperty in place of ForceSet,
2015-10-29 11:21 GMT+02:00 Jakob Kummerow :
> Most flags are for debugging and development
"Most flags are for debugging and development" - that's exactly what I need
them for.
In particular, I want to limit memory amount that Isolate can use.
--
--
v8-users mailing
12 matches
Mail list logo