BinaryHeap.insert, conditionalInsert and replaceFront all call assertValid, which goes through the complete heap to check for correct structure. This results in unusable performance in debug mode due to the quadratic run time. Arguably, such costly algorithm validation should be left for a unit test instead.
A similar issue with RedBlackTree container: https://d.puremagic.com/issues/show_bug.cgi?id=12246
I think implying "unittest => slow but checked containers" is not the way to go, either. Imagine a module making heavy use of containers and just wishing to run the module's own unittests. With such implication, there would be no fast way to do that. Or is there a way to import the generic container from std.container without propagating the "-unittest" flag? It's a generic after all, so it can't be compiled separately, right? A better way would be to (create and) mention a version flag needed for container debugging in the documentation for the respective container.
I have put them in debug(BinaryHeap) https://github.com/D-Programming-Language/phobos/pull/1976
Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/2a32a6382167627aab2318093a93b9987b0b8417 Fix Issue 12245 - BinaryHeap expensive in -debug https://d.puremagic.com/issues/show_bug.cgi?id=12245 https://github.com/D-Programming-Language/phobos/commit/43d01952ac09ac451bb664c961e006d489c6f665 Merge pull request #1976 from Poita/bug12245 Fix Issue 12245 - BinaryHeap expensive in -debug