Should fast mime detection use a stat call?

[Mark]

-- sending to kfm-devel as well --

Hi,

By now some of you have likely seen my reviewrequest [1] that greatly
speeds up fast mime detection. In fact, the speedup is ~13x over the
current situation. I only stopped profiling and further speeding it up
because initialization and KGlobal calls began to float on top of the
profiling.

While profiling that and filling the reviewrequest i found some issues
that warrant a bit further discussion. Hence this thread.

Issue 1: We overwrite the user specified "is_local_file" [2] line 321
If you look at the code from line 321 you see that we reset the user
provided "is_local_file" if we manually detected that
"url.isLocalFile()" equels to true. Now i wonder if that's the
intended behavior since we are resetting a user provided value. A
result of this (for local files) is that findFromMode is called from
line 192 (same file as [2]). That function is executing a stat call on
line 92 (again same file). So the question is: Should we want this
when the user explicitly asks us for fast results by setting
"fast_mode" to true and setting "is_local_file" to false. Even though
the files might be local ones? One app that is doing this is the file
chooser dialog. I haven't checked it's code, but the results seem to
indicate that it's doing exactly as described. Adding the stat call
back makes the code in [1] still faster in then the current fast mime
detection, but only by about 5x instead of 13x. I think we should not
change the user provided values. However, then you hit "Issue 2".

Issue 2: Folders without a trailing slash are not detected as folders.
Oke, this issue is imho as it should be. If you provide something
like: "file:///home/youruser/somefolder" then it is impossible to
detect "somefolder" as a folder without doing a stat call. I guess
that's why the above "Issue 1" exists in the first place since adding
a stat call will "fix" it. Fast mime detection with a trailing slash
"file:///home/youruser/somefolder/" for folders proved to be quite
accurate and very fast in my testing. It's just that the user has to
provide that trailing slash. Something which the file chooser dialog
is not doing so i suppose more apps don't do that. My question now is:
can i expect the user applications to provide a trailing slash for
folders thus prevent the stat call and be ~13x faster then the current
fast mime detection? Or should i expect the user to be stupid and
neglect the trailing slash which means that i have to do a stat call
which drops the speedup to "just" ~5x faster? Doing the first means
fixing up apps that's don't provide a trailing slash for folders.

What's your opinion on this? My intention is to have fast mime lookup
be really fast and don't do any stat calls at all which is the patch
in [1]. Stat calls even seem like a waste because you are very likely
to have just done a stat call just to get the file list. However, that
stat data isn't send to KMimeType so another way would be to require a
"KFileItem" which knows more about a file instead of a KUrl (QUrl in
kde frameworks). But then again, that requires app side changes...

[1] https://git.reviewboard.kde.org/r/111050/
[2] http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=d7485238a06ab22321b51735dd545bca823d6976&hb=ee752b59aaa9b27bd1134fbb63c0600b94af516e&f=kdecore%2Fservices%2Fkmimetype.cpp