Hi Ben, thanks for your reply, I was a little worried because my initial web searches did not find obvious reports of this issue by others (too much noise perhaps).
> For V8 3.14 / node.js v0.10, I fixed most of the overhead by means of > PR [0], what I think you call a poor man's hack in your email. Not > that I disagree, but it's remarkably effective. :-) Oops, I didn't mean to imply it is _necessarily_ an incorrect or bad solution. I was really thinking in the context of my own implementation, which was "tactical" and intended purely to give me confidence I was on the right track while debugging. My cautious thinking was that the downside would be a potential delay in the processing of the next batch of work (samples or code events) leading to an increase in the queue length. If that worry is unfounded, it could be a quite pragmatic solution and it sounds like you were able to get an acceptable reduction in CPU utilisation with a very small sleep period. It would be interesting to compare the behaviour of the 1 ns sleep implementation vs a semaphore implementation. sched_yield() only gives up a time slice when there is another process scheduled on the same CPU. I changed that to a nanosleep() call with a 1 ns timeout that forcibly puts the thread to sleep, with the timeout getting rounded up to operating system granularity (50 us on most Linux systems, it's even coarser on OS X.) I also found a sleep quite effective at reducing the CPU usage, but I haven't checked the effects with any particular depth (at least, not yet). I tried 1, 10 and 100 microsecond sleeps. 1 and 10 seemed to give a similar reduction in utilisation, which makes sense if the minimum scheduler granularity was >10 microseconds on my box. A 100 microsecond sleep appeared to give a better utilisation reduction. To give ballpark figures, the profiler processing thread clocked ~100% normally, ~20% with a 1 or 10 us sleep and ~15% with a 100 us sleep. ---- I ran a test on a recent V8 version (a late December cut of master from v8-git-mirror) while capturing a perf profile, and it looks like the samples are mostly spent reading the current time: - 97.41% [kernel] [k] acpi_pm_read - acpi_pm_read - 99.98% ktime_get_ts - posix_ktime_get_ts - sys_clock_gettime - system_call_fastpath - 0x7fffc5bfe7c2 - __clock_gettime - 95.34% v8::base::ElapsedTimer::Now() - 97.86% v8::base::ElapsedTimer::Elapsed() const v8::base::ElapsedTimer::HasExpired(v8::base::TimeDelta) const v8::internal::ProfilerEventsProcessor::Run() v8::base::Thread::NotifyStartedAndRun() v8::base::ThreadEntry(void*) start_thread + 2.14% v8::base::ElapsedTimer::Start() So it looks like the thread won't yield time slices as it did in 3.14. Regards Michael -- -- 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 an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.