With glue I mean just calling the js_reply_async function from javascript: 
1. I start measuring time in javascript. 
2. I call the js_reply_async function 
3. I start measuring time in C++
4. I do some preprocessing, start a worker thread, and do some 
post-processing. 
5. I stop measuring time in C++
6. I call the javascript callback
7. I stop measuring time in javascript. 
Still a difference of 2 ms between the two time measurements.

The variable delay is already included in the time measurement: I start 
measuring time before the work is pushed to the queue, and stop measuring 
after it is finished. 

On Friday, May 2, 2014 1:07:22 AM UTC+2, Ben Noordhuis wrote:
>
> On Thu, May 1, 2014 at 4:34 PM, Kees k <[email protected] <javascript:>> 
> wrote: 
> > Managed to solve this problem. The same piece of code takes now  < 100 
> usec. 
> > 
> > Strange thing is still that there is a big difference when i measure the 
> > execution time of my whole modbus reply function when measured from 
> > javscript or in c++. 
> > 
> > C++ code takes only 5 ms to execute, but the additional javascript glue 
> adds 
> > another 2 ms on top of this. Does anyone now what the glue does? Does 
> this 
> > result from dynamically loading a large size *.node file? 
> > 
> > Async call to reply function 
> >> 
> >> Handle<Value> js_reply_async(const Arguments& args) { 
> >> 
> >>      reply_t* reply = new reply_t; 
> >>      clock_gettime(CLOCK_MONOTONIC, &reply->tstart); 
> >>      ... 
> >>      uv_work_t* req = new uv_work_t(); 
> >>      req->data = reply; 
> >>      uv_queue_work(uv_default_loop(), req, reply_work, 
> (uv_after_work_cb) 
> >> reply_after); 
> > 
> > Just before performing the callback to javascript 
> >> 
> >> clock_gettime(CLOCK_MONOTONIC, &reply->tstop); 
> >> reply->cb->Call(Context::GetCurrent()->Global(), 1, argv); 
> >> reply->cb.Dispose(); 
> >> printf("Startaddress %d offset %d ts %lu s, %lu ns\n", ((reply->req[2] 
> >> <<8) | reply->req[3]), ((reply->req[4] <<8) | reply->req[5]), 
> >> reply->tstop.tv_sec-reply->tstart.tv_sec, 
> >> reply->tstop.tv_nsec-reply->tstart.tv_nsec); 
> > 
> > And my javascript 
> >> 
> >> var starttime = timers.nanotime(timers.CLOCK_MONOTONIC); 
> >> mb.reply(self.ctx, query, len, startAddress, offset, data, 
> >> self.settings.nrRegisters, function(error){ 
> >>         var stoptime = timers.nanotime(timers.CLOCK_MONOTONIC); 
> >> console.log("startAddress " + startAddress + "\tlen " + len + 
> "\tduration 
> >> "+ ((stoptime.sec * 1000 + stoptime.nsec / 1e6) - (starttime.sec * 1000 
> + 
> >> starttime.nsec / 1e6)) + " ms"); 
> >> } 
>
> I'm not entirely sure what you mean by glue but if it's 
> uv_queue_work() that you're referring to, that executes the work in a 
> shared, fixed-size thread pool.  That inevitably adds (variable) 
> latency. 
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to