Implement new file reader #16
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I wasn't aware of this. I did something similar at quark-zju@305b3ac. It has some caching support. |
|
How much does/would caching help? The kernel is already doing all that for you, so all you're saving is the cost of the syscalls themselves. There can't be that many of them since you'd be limited by the user's reading rate (and bulk operations like search can amortize the cost with large reads). |
|
I'm not sure. Each line will trigger a |
markbt
force-pushed
the
new-files
branch
2 times, most recently
from
d0f7968
to
914af4d
Compare
Implement a new reader for on-disk files, that reads the data out of the file rather than mmapping it. Reads to the file for display and search go through an LRU cache of 1MB blocks. If a file change is detected, then depending on whether or not the file has been appended to or rewritten, streampager will load the remaining data or flush its caches and reload the file. The heuristic for append-vs-reload is whether the last 4k of the file has changed or not, or if any time we try to parse a line we find a newline in the middle of the line. This replaces the mmap implementation, giving a better experience for looking at files on disk. The mmap implementation is retained in case it will be useful, but for now is unused. Fixes #8 Fixes #9
|
I added cache support, so now this is probably ready to go. Any input welcome before I merge it. The notify behaviour seems a bit unreliable, but when it works, it's quite nice. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement a new reader for on-disk files, that reads the data out of the file
rather than mmapping it.
It's a bit simple right now, so it reloads each line from the file whenever it
wants to display it. It would be better to go through some kind of LRU block
cache for loading chunks of the file. The cache can be flushed whenever we
detect a reload is necessary.
The heuristic for append-vs-reload is whether the last 4k of the file has
changed or not. Also, any time we try to parse a line and fine a newline
in the middle of the line, we trigger a full reload.
This should help with #8 and #9, as we now watch the file and load new contents
if the file is appended to, or reload the file if the contents change or the
file is truncated.
The mmap implementation is retained in case it will be useful, but for now is
unused.