Skip to content

Commit

Permalink
Corrected error in timing, definitely accurate now
Browse files Browse the repository at this point in the history
  • Loading branch information
benashford committed Mar 23, 2014
1 parent 8f54dc3 commit fd7b7a5
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions _posts/2014-03-22-the-power-of-lazy-sequences.md
Expand Up @@ -38,24 +38,24 @@ lazysort.core> (time (do (doall (lazysort rand-nums)) nil))

Yep, as expected, it's quite a bit slower. So where, exactly, do the optimisations of lazy sequences manifest themselves? One significant benefit is short-cutting. Lazy evaluation can be stopped when no-further results are expected and/or needed, this could leave a significant amount of work undone.

So going back to our vector of random numbers, what if we didn't care about the precise order of everything? What if we only wanted the first 100 items from the sorted sequence?
So going back to our vector of random numbers, what if we didn't care about the precise order of everything? What if we only wanted the first ten items from the sorted sequence?

Built-in ```sort```:
<pre>
lazysort.core> (time (take 100 (sort rand-nums)))
lazysort.core> (time (doall (take 100 (sort rand-nums))))
"Elapsed time: 39.693 msecs"
(11 60 80 88 110 131 132 145 178 179 193 216 253 256 311 344 354 381 424 424 477 478 520 527 646 658 676 677 684 696 716 721 737 775 812 821 843 848 864 902 939 939 947 949 949 962 969 980 989 1064 1069 1075 1173 1196 1199 1204 1209 1218 1236 1240 1285 1293 1346 1359 1369 1432 1477 1494 1508 1518 1553 1560 1603 1672 1710 1719 1772 1775 1795 1797 1824 1856 1864 1895 1932 1940 2020 2021 2075 2088 2098 2102 2105 2126 2143 2157 2164 2263 2263 2279)
</pre>

The performance is about the same, in the region of 40 milliseconds. This is expected, of course, the whole 50,000 items are being sorted before the first 100 items are picked. Let's try ```lazysort```:

<pre>
lazysort.core> (time (take 100 (lazysort rand-nums)))
"Elapsed time: 0.044 msecs"
lazysort.core> (time (doall (take 100 (lazysort rand-nums))))
"Elapsed time: 22.06 msecs"
(11 60 80 88 110 131 132 145 178 179 193 216 253 256 311 344 354 381 424 424 477 478 520 527 646 658 676 677 684 696 716 721 737 775 812 821 843 848 864 902 939 939 947 949 949 962 969 980 989 1064 1069 1075 1173 1196 1199 1204 1209 1218 1236 1240 1285 1293 1346 1359 1369 1432 1477 1494 1508 1518 1553 1560 1603 1672 1710 1719 1772 1775 1795 1797 1824 1856 1864 1895 1932 1940 2020 2021 2075 2088 2098 2102 2105 2126 2143 2157 2164 2263 2263 2279)
</pre>

0.04 milliseconds! Or 1/1000th of the time of the eagerly-sorted version. Being able to stop early saves significant time. There are literally hundreds of cases when this kind of short-cut is done in large applications, and shows how much of a benefit lazy sequences and lazy evaluation generally can actually have.
It only requires half the time, being able to stop early saves significant time. There are literally hundreds of cases when this kind of short-cut is done in large applications, and shows how much of a benefit lazy sequences and lazy evaluation generally can actually have.

Footnotes:

Expand Down

0 comments on commit fd7b7a5

Please sign in to comment.