rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long filename and not a short one (on Windows), that
is not a symlink, that is relative or absolute (pick one or both).
This could work, though it looks as if we're duplicating what QFileInfo
does, and we might run into similar problems about caching to what we
had before. I don't know---but I think this makes some sense out of why
they want to return false if the files don't exist. The problem, as I
see it, is that QFileInfo objects are getting created so often, which
requires filesystem access, even independently of the caching stuff. And
I'm not sure how that can be avoided.
Anyway, here's another idea. Why are we calling loadIfNeeded() every
time? It's there that the check is made that the file is loaded in a
buffer, which (if I'm remembering right) calls == to see. It seems to me
that there are only a few occasions when a file could need to be loaded
if it wasn't before. E.g., if an InsetInclude has been added or
modified; or if the default master has been changed. So maybe we could
have some flag, maybe in the BufferList, that meant: you don't need to
check this, nothing has changed. And it could be set and cleared by e.g.
InsetInclude constructors.
Wouldn't it be better to remove the check completely? Instead of
checking if we need to call "loadIfNeeded" all the time - don't.
Instead, check (and loasd) only when an insetinclude is changed/modified.
That way, the test don't merely get cheaper, the test goes away which is
even better.
I don't think there are that many cases to
consider. And of course, similar problems could arise elsewhere, and
they'd need similar solutions. But it bothers me that we're checking
whether every needed file is loaded every time we type a key.
Seems excessive indeed. Ideally, typing text should be fine even with a
"sleep(1)" in every filesystem interface. Just a slight stop whenever
the emergency save happens.
We can't assume that filesystem access will be quick.
Helge Hafting
