Should of done these patches ages. I've long trumped it faster to read an SDfile as follows in CDK 1.5/2.0:

IAtomContainer mol;
while ((mol = mdlr.read(new AtomContainer(0,0,0,0)) != null) {
  // do stuff
}

This is fast but is unfortunately not fault tolerant. In real life SDfile have junk in them and so we fall back to the slower IteratingSDFReader.

ChEBI 149 with MDLV2000Reader

real	0m9.367s
user	0m18.152s
sys	0m1.280s

ChEBI 149 with IteratingSDFReader

real	0m14.085s
user	0m26.541s
sys	0m1.820s

IteratingSDFReader actually contains some of the first patches I made to CDK. Looking at it 5 years wiser I realised some simple changes could bring this down to the same speed.

Step 1. Replace the synchronized StringBuffer with StringBuilder:

real	0m12.892s
user	0m23.833s
sys	0m1.536s

Step 2. Avoid redundant memcpy (string.getBytes()), use string prefix matching instead of REGEX, and only check the V2000/V3000 line on the line it must be in:

real	0m10.840s
user	0m22.426s
sys	0m1.422s

I think tweaked the data header/block reading a little. Hopefully Greg Landrums push towards an Open Molfile push. Technically you can have an SDF record separator not be counted as such when it's in a data value:

> <HEADER>
$$$$

> <Next>

However I can not see a genuine use case for that, whilst I can see this happening by accidient:

> <HEADER>
$$$$

   CDK

999999 0 0 0 0 V2000 etc..