#line annotation costly to generate because of too much I/O

[nddrylliog]

See:

amos at loki in ~/Dev/rock (97x)
$ time rock rock.use --onlygen
[ OK ]
rock rock.use --onlygen  11.14s user 0.24s system 99% cpu 11.396 total

versus:

amos at loki in ~/Dev/rock (97x)
$ time rock rock.use --onlygen --nolines
[ OK ]
rock rock.use --onlygen --nolines  5.44s user 0.11s system 99% cpu 5.558 total

A whopping half the time taken by line numbers! It's because we read the file every time. We gotta have at least some sort of caching system for .ooc files being read.. or better yet, Tokens storing line numbers directly when being read.

[nddrylliog]

This has been observed on Windows and it seems to have a huge impact. We have indeed a few million I/O reads (O_O) because we seek so much in files and the like.

As a temporary stopgap measure, instead of implementing a byte offset <=> line number map, we could just read whole files in memory and work from there. It'd still be stupid but a whole lot more efficient.

[nddrylliog]

The solution was to make nagaqueen expose its own line info, which it already has. No need to recompute it all the time ourselves!