-- 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
