Code improvement for DNA reverse complement?

ag0aep6g via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri May 19 06:38:20 PDT 2017


On 05/19/2017 02:55 PM, Biotronic wrote:
> On Friday, 19 May 2017 at 12:21:10 UTC, biocyberman wrote:
>>
>> 1. Why do we need to use assumeUnique in 'revComp0' and 'revComp3'?
> 
> D strings are immutable, so if I'd created the result array as a string, 
> I couldn't change the individual characters. Instead, I create a mutable 
> array, change the elements in it, then cast it to immutable when I'm 
> done. assumeUnique does that casting while keeping other type 
> information and arguably providing better documentation through its 
> name. Behind the scenes, it's basically doing cast(string)result;

You could alternatively use `.reserve` on a `string`:

----
string result;
result.reserve(N);
for (...) {
    result ~= ...;
}
----

That performs worse, though. Probably still has to check every time if 
there's reserved space available. On the plus side, it would be `@safe`.

>> 2. What is going on with the trick of making chars enum like that in 
>> 'revComp3'?
> 
> By marking a symbol enum, we tell the compiler that its value should be 
> calculated at compile-time. It's a bit of an optimization (but probably 
> doesn't matter at all, and should be done by the compiler anyway), and a 
> way to say it's really, really const. :p

You fell into a trap there. The value is calculated at compile time, but 
it has copy/paste-like behavior. That is, whenever you use `chars`, the 
code behaves as if you typed out the array literal. That means, the 
whole array is re-created on every iteration.

Use `static immutable` instead. It still forces compile-time 
calculation, but it doesn't have copy/paste behavior. Speeds up revComp3 
a lot.


More information about the Digitalmars-d-learn mailing list