Performance of ranges verses direct

Nikolay sibnick at gmail.com
Fri Dec 13 10:03:26 PST 2013


I found that performance of ranges is miserable in many cases. 
You should not use them if there is any chance for big/critical 
computations. Actually I don't like to have two subsets of 
language: one with good performance, and other with good 
maintainability/readability. I have a couple thought about this 
situation. May by we can use CTFE and mixin for inlining some 
range based code on library level?

FYI One of my benchmark (calculate sum of two simple ranges):
#!/usr/bin/rdmd

module zip_test;

import std.range;
import std.datetime;
import std.getopt;
import std.stdio;
import std.algorithm;


struct Range{
         uint count = 0;
         @property bool empty(){
                 return count>=limit;
         }
         @property int front(){
                 return count;
         }
         bool popFront(){
                 count++;
                 return count<limit;
         }
}

uint testForEach(){
         Range r1, r2;
         uint rs = 0;
         for(int i=0; !r1.empty && !r2.empty; i++){
                 rs += r1.front + r2.front;
                 r1.popFront();
                 r2.popFront();
         }
         writefln("foreach: %s", rs);
         return rs;
}
uint testZip(){
         Range r1, r2;
         auto tmpRange = step1(r1, r2);
         auto rs = reduce!(q{ a + b })(0U, tmpRange);
//      auto rs = reduce!((a,b) => a + b)(0U, tmpRange);
         writefln("zip: %s", rs);
         return rs;
}

auto step1(Range r1, Range r2){
         //return zip(r1, r2).map!(a => a[0]+a[1]);
         return zip(r1, r2).map!(q{a[0]+a[1]});
}

uint limit = 10_000;

void main(string[] args){
         getopt( args, "limit", &limit);
         auto r = benchmark!(testForEach, testZip)(10);
         foreach(idx, rs; r){
                 writefln("%s - %s", idx, rs.msecs);
         }
}

Results:
~/ldc2-0.12.0-linux-x86_64/bin/ldmd2 -O -release -inline 
zip_test.d
./zip_test --limit 10000000
…........
0 - 0
1 - 764


More information about the Digitalmars-d-learn mailing list