<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Gabor,<br>
<br>
With that said about it being a micro benchmark, by-without-by
might be at play in GG2(X,Y) here; i.e. running j for each row of
i, where it could run once. I remember you and others quite
rightly said by-without-by should be explicit ... still got to
make that change. A similar speed issue came up recently
somewhere else as well which the change in default should help.<br>
<br>
Matt<br>
<br>
On 02/02/14 18:57, Matt Dowle wrote:<br>
</div>
<blockquote cite="mid:52EE9527.10608@mdowle.plus.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
But this is at the *micro* second level ?!!<br>
<br>
I confirm those results on my slow netbook but remember these
are **micro** seconds i.e. 71,000 here is less than 0.1 of a
second.<br>
<br>
> microbenchmark(flodel(X,Y), GG1(X,Y), GG2(X,Y))<br>
Unit: microseconds<br>
expr min lq median uq
max neval<br>
flodel(X, Y) 330.798 369.369 402.7935 455.3225
17996.26 100<br>
GG1(X, Y) 14287.380 14370.038 14466.5990 16010.5440
121082.77 100<br>
GG2(X, Y) 71164.270 85751.437 107951.3415 161676.5720
366003.62 100<br>
<br>
To put it in some perspective :<br>
<br>
> system.time(GG2(X,Y))<br>
user system elapsed <br>
0.072 0.000 0.072 <br>
> system.time(GG2(X,Y))<br>
user system elapsed <br>
0.080 0.000 0.079 <br>
> system.time(GG2(X,Y))<br>
user system elapsed <br>
0.072 0.000 0.072<br>
<br>
Where those times are in seconds. So the task in question
here, takes 0.07 seconds ?!<br>
<br>
The 150x longer figure is actually (using figures from the S.O.
answer) 24695 microseconds (i.e. 0.024 seconds) divided by 168
microseconds (0.000168 seconds). 0.024 seconds / 0.000168 =
"150 times". If you rounded to milliseconds you could say
data.table is infinitely slower (24ms / 0ms = Inf).<br>
<br>
I can believe there's scope for improvement, sure, but not from
this benchmark. The vectors need to be *much* bigger and
replications needs to be *much* smaller, say 3. The task being
timed needs to take a meaningful amount of time (say 5 seconds)
*for a single run*.<br>
<br>
Matt<br>
<br>
<br>
On 02/02/14 12:27, Gabor Grothendieck wrote:<br>
</div>
<blockquote
cite="mid:CAP01uRno0PLSLOmA=vQ8L2PU+XTM79AnP7fko2iFR9qsy_7v9A@mail.gmail.com"
type="cite">
<div dir="ltr">The benchmark at the bottom of this post shows a
problem where a data.table roll="next" took nearly 150x longer
than a base findInterval() solution. (The data.table solution
is easier to write though.) This suggests an area for possible
speed improvement.
<div> <br>
<div><a moz-do-not-send="true"
href="http://stackoverflow.com/questions/21499742/fast-minimum-distance-interval-between-elements-of-2-logical-vectors-take-2/21500855#21500855">http://stackoverflow.com/questions/21499742/fast-minimum-distance-interval-between-elements-of-2-logical-vectors-take-2/21500855#21500855</a><br
clear="all">
<div><br>
</div>
-- <br>
Statistics & Software Consulting<br>
GKX Group, GKX Associates Inc.<br>
tel: 1-877-GKX-GROUP<br>
email: ggrothendieck at <a moz-do-not-send="true"
href="http://gmail.com" target="_blank">gmail.com</a><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
datatable-help mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:datatable-help@lists.r-forge.r-project.org">datatable-help@lists.r-forge.r-project.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help</a></pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>