More embarrassing microbenchmars for D's GC.

[Rounin]

>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.