Speeding up text file parser (BLAST tabular format)

[John Colvin via Digitalmars-d-learn]

On Monday, 14 September 2015 at 13:58:33 UTC, Fredrik Boulund 
wrote:
> On Monday, 14 September 2015 at 13:37:18 UTC, John Colvin wrote:
>> On Monday, 14 September 2015 at 13:05:32 UTC, Andrea Fontana 
>> wrote:
>>> On Monday, 14 September 2015 at 12:30:21 UTC, Fredrik Boulund 
>>> wrote:
>>>> [...]
>>>
>>> Also if problem probabily is i/o related, have you tried with:
>>> -O -inline -release -noboundscheck
>>> ?
>>
>> -inline in particular is likely to have a strong impact here
>>
>
> Why would -inline be particularly likely to make a big 
> difference in this case? I'm trying to learn, but I don't see 
> what inlining could be done in this case.

Range-based code like you are using leads to *huge* numbers of 
function calls to get anything done. The advantage of inlining is 
twofold: 1) you don't have to pay the cost of the function call 
itself and 2) often more optimisation can be done once a function 
is inlined.

>>> Anyway I think it's a good idea to test it against gdc and 
>>> ldc that are known to generate faster executables.
>>>
>>> Andrea
>>
>> +1 I would expect ldc or gdc to strongly outperform dmd on 
>> this code.
>
> Why is that? I would love to learn to understand why they could 
> be expected to perform much better on this kind of code.

Because there are much better at inlining. dmd is quick to 
compile your code and is most up-to-date, but ldc and gdc will 
produce somewhat faster code in almost all cases, sometimes very 
dramatically much faster.