Oh, and another possible issue would be that LDC currently heap-allocates array literals for enums on each function entry in some cases where even DMD doesn't do it.
Re-enabling the gc2stack pass with its unused allocation detection would fix this problem as a nice side-effect, but unfortunately it seems to uncover a problem somewhere in the function type handling code (see https://github.com/ldc-developers/ldc/pull/206). David On Sat, Nov 3, 2012 at 11:44 AM, David Nadlinger <[email protected]>wrote: > Hi, > > On Sat, Nov 3, 2012 at 6:43 AM, <[email protected]> wrote: > >> The only thing I can think of that makes this code different from others >> I've written in the past is that it makes extensive use of associative >> arrays. Is there any reason why this might be particularly problematic >> with LDC? > > > the only really good answer to this question is profiling. > > However, one guess would be that the LDC build system currently creates a > debug build of druntime and Phobos by default. This is probably enough to > create a significant slowdown in many applications, and AA-heavy code will > probably call quite a few druntime functions. > > This definitely needs to be changed, but I guess the best solution would > be to reactivate the -defaultlib/-debuglib mechanism and build two copies > of Phobos/druntime as part of the standard build process. > > To test whether this is really the cause for the slowdown, you can just > modify the D_FLAGS variable in CMake accordingly, e.g. set it to > -d;-O3;-release. > > David > --
