Maybe this is CTFE to blame more than the function itself.

I have a project where I have a TypeTuple that holds a class tree of a wrapped C++ library. The tuple is iterated from in several places where an index has to be retrieved. Compiling this project takes 46 seconds when using staticIndexOf and uses 700 MB RAM. If I replace it with my own hardcoded function below it takes only 5 seconds and uses 150 MB RAM. This is what the function looks like:

template myStaticIndexOf(T, TList...)
{
    static if (is(typeof(T == TList[0])) && is(T == TList[0]))
        enum myStaticIndexOf = 0;
    else
    static if (is(typeof(T == TList[1])) && is(T == TList[1]))
        enum myStaticIndexOf = 1;
    else
    // ... and so on ...
}

The body is pregenerated of course, using mixin() would slow down
compilation here as well.

When wrapping larger libraries (and hence having a larger TypeTuple) and using staticIndexOf the memory usage becomes so high that the compiler runs out of memory and crashes.

I really think it sucks that I have to resort to manually pre-generating a function body externally as if I were using a lame (CTFE-wise) language like C++03.

D *has* to be better than this..

On Sunday, 26 August 2012 at 21:03:31 UTC, Andrej Mitrovic wrote:
> Maybe this is CTFE to blame more than the function itself.
>
> I have a project where I have a TypeTuple that holds a class tree of a
> wrapped C++ library. The tuple is iterated from in several places
> where an index has to be retrieved. Compiling this project takes 46
> seconds when using staticIndexOf and uses 700 MB RAM.

Do you have a minimal repro case for this? It makes it a lot easier to track down the problem if we have a solid repro case that we can test.

On 8/26/12, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> Do you have a minimal repro case for this?

http://dpaste.dzfl.pl/4a267350

win32 using timeit:

$ timeit dmd -version=OLD myStaticIndex.d
Done in 626 msecs.

$ timeit dmd -version=NEW myStaticIndex.d
Done in 183 msecs.