Looking for a Code Review of a Bioinformatics POC

[H. S. Teoh]

On Thu, Jun 11, 2020 at 11:02:21PM +0000, duck_tape via Digitalmars-d-learn wrote:
[...]
> I will give that a shot! Also of interest, the profiler results on a
> full runthrough do show file writing and int parsing as the 2nd and
> 3rd most time consuming activities:
> 
> ```
>   Num          Tree        Func        Per
>   Calls        Time        Time        Call
> 
> 8942869       46473       44660           0     void app.IITree!(int, bool).IITree.overlap(int, int, void delegate(app.IITree!(int, bool).IITree.Interval))
> 8942869       33065        9656           0     @safe void std.stdio.File.write!(char[], immutable(char)[], char[], immutable(char)[], char[], immutable(char)[], int, immutable(char)[], int, char).write(char[], immutable(char)[], char[], immutable(char)[], char[], immutable(char)[], int, immutable(char)[], int, char)
> 20273052       10024        9569           0     pure @safe int std.conv.parse!(int, char[]).parse(ref char[])

Hmm, looks like it's not so much input that's slow, but *output*. In
fact, it looks pretty bad, taking almost as much time as overlap() does
in total!

This makes me think that writing your own output buffer could be
worthwhile.  Here's a quick-n-dirty way of doing that:

	import std.array : appender;
	auto filebuf = appender!string;
	...
	// Replace every call to writeln with this:
	put(filebuf, text(... /* arguments go here */ ..., "\n"));

	...

	// At the end of the main loop:
	enum bufLimit = 0x1000; // whatever the limit you want
	if (filebuf.length > someLimit) {
		write(filebuf.data); // flush output data
		stdout.flush;
		filebuf.clear;
	}

This is just a rough sketch for an initial test, of course.  For a truly
optimized output buffer I'd write a container struct with methods for
managing the appending and flushing of output. But this is just to get
an idea of whether it actually improves performance before investing
more effort into going in this direction.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter