>Keep in mind that D associative arrays are usually slower than Python dicts. >Probably you build data structures like associative arrays, and this slows down >the GC. If you disable&enable the GC around that build phase, the program is >probably fast (so I suggest you to narrow as much as possible the width of the >disable/enable span, so you may see where the GC problem is). If you put a >exit(0) at the end of the program (to kill final collection) the D program may >save more time. This could be the case, as I started noticing the slowdown as I was writing either the second or third block, which is where I build a ton of data structures.
Complicating the code by avoiding associative arrays isn't really an option, though, as the whole point of writing the program was comparing D to Python in terms of simplicity. Turning off the garbage collector during time-critical bits is simple enough, though, as long as one knows that it has to be done. >What do you mean? If there's a bug in splitlines() or split() it's better to >add >it to Bugzilla, possibly with inlined string to split (no external file to >read). >splitlines() or split() are simple functions of a module, written in D, so if >there's a problem it's usually not too much hard to fix it, they are not >built-in >methods written in C as in CPython. There's no bug in split() as far as I know, but during development of the program, splitlines() would split the data on other things than newlines. It could be a bug in D, but it could just be a temporary glitch in the code, so I'm not filing a bug.
