| |
![Walter Bright's Gravatar profile Gravatar of Walter Bright](//www.gravatar.com/avatar/12afde220e4ce94ad89f6598f7686f32?d=identicon&s=32) | Posted by Walter Bright in reply to Adam D Ruppe | Permalink Reply |
|
Walter Bright ![Walter Bright's Gravatar profile Gravatar of Walter Bright](//www.gravatar.com/avatar/12afde220e4ce94ad89f6598f7686f32?d=identicon&s=80)
Posted in reply to Adam D Ruppe
| On 5/8/2023 5:32 PM, Adam D Ruppe wrote:
> I wouldn't separate out column/line/file at all. Concatenate all the files together in memory and store only an offset into that gigantic array. If an error happens, then and only then go back to extract the details by slicing the filename out of a listing and rescanning it to determine line and column. (You'd probably have an index that does a bit of both, like every new file or every 5000 lines, add an entry to the lookup table. Then when you do hit an error, you just need to scan from the closest point forward instead of the whole thing.)
>
> If there's no errors, it uses little memory and is fast. If there is an error, the rescanning time is not significant anyway relative to the time to fix the error.
Thinking about it a bit more, it isn't necessary to concatenate the files at all. Just, for each file, record the starting line number, which would be the sum of all the lines in the files previously parsed.
Then, the line number can be converted to file/line by looking up the range of line numbers it falls in, which gives the file, and subtracting the corresponding starting line number, which gives the line.
So if we leave 8 bits for column, 1..256, that gives 24 for the line number, which gives room for 16,777,216 lines which ought to be enough, and no rescanning necessary.
|