Feature Req: Pls "cache" file info to speed up app

[l_d_allan]

ExifToolGui newbie, so "consider the source"

Thanks for providing and maintaining ExifToolGui. I'm finding it very useful.

Something I've noticed ... if the directory has 100's of files in it, it can take quite a while for ExifToolGui to be ready to interact with the directory. Then if I switch directories and then go right back to the previously opened directory with 100's of files, it seems to have to redo all the reading and processing.

So the idea of caching might be worth considering. My observation is that this makes a very significant difference with CS5 Bridge.

I've got a pretty fast computer with fast drives, so I don't think the issue is an obsolete computer (i7-2600K with SSD and 1.5tb WD "black" HDD, and 16gb DRAM).

Granted, this feature request might be quite a bit of effort to develop, and tough to test .... but ...

And certainly, this would fall into the category of "nice to have" and thus not all that high of priority.

Again, thanks for the time and effort you've put into ExifToolGui!

[pb]

This is something that has been commonly done for literallly decades.  It still allows a vast performance improvement, because disks are slow, and most file systems are not designed for rapid directory reading.

However, there is a problem:  the cache can become out of date.  There are 2 ways to solve that:

1.  Leave it up to the user.
2.  Ask the OS for notifications of changes to the directory.

(1) is fairly easy to implement.
(2) is harder, and probably will involve bizarre behavior by various Windows versions.

Note that changing this in gui will not help the fact that for operations with wildcards, exiftool itself will probably still have to do its own directory requests.

--peter

[BogdanH]

Hi allan,

As I mentioned in manual, the speed of filelist creation after changing directory depends on Details view you choose:
Standard filelist
-here, filelist should be populated almost instantly even on very slow PC.

Camera settings, Location info and About photo view
When using any Details view other than Standard, speed will decrease, because each file is parsed for metadata. How much speed will decrease, depends on number of files (of course) and on size of each file. If we are dealing with small (say, up to 2MB) jpg files, then parsing is still relative fast, because Windows caches small files completely and delivers them fast to GUI. However, for larger files (say, above 8MB) this isn't the case. Note: it's OS (Windows) who delivers file to GUI.
Camera settings view is still somewhat faster than other two, because only Exif metadata is parsed (otherwise Exif and Xmp metadata is parsed). Anyway, in all three cases, metadata is parsed by GUI and it only takes few msec per file. That is, the speed mainly depends on how fast OS can deliver complete file.

User defined view
-is the slowest of them all, because ExifTool is called for parsing metadata from each file. Of course, as mentioned before, file size plays very important role here as well.

I suggest that, when fast browsing thru directories, you do that in Standard filelist view and if necessary, change Details view after you're found files you're looking for.
Impementing file caching inside GUI would just make it "memory hog" -there are some, who keep thousands of files in single directory!?

Bogdan

[pb]

Wouldn't it be more efficient to parse only the file whose metadata is to be displayed?

--peter

[BogdanH]

hi peter,

You're right, of course. If I would start from scratch again, I would definitely do it that way. But I don't plan to make any "major" changes in near future. Truth is, my enthusiasm about GUI isn't particulary high right now -could be I need a new challenge.. or I'm just getting lazy 

Bogdan

[pb]

Well, variety is the spice of life.  Working on the same thing for years on end can get boring.  Of course, if you could figure out how to make it open source, other people could contribute.  (I think at some point you said there was someone else's proprietary stuff in there precluding that...)

--peter

[BogdanH]

hi peter,

Well, variety is the spice of life.  Working on the same thing for years on end can get boring.

-you've described it perfectly.
Yes, some of code I use isn't open/freeware, so publishing only my source would be useless. On the other hand, GUI isn't that "important project" and I can hardly imagine one would be willing to spend time for "improvements" (I don't consider changing color on buttons as an improvement, though). IMO, if someone would have a will and some freshy ideas, he would allready make something new in this direction.
Or let me put it this way: the only important thing is communication between GUI and ExifTool -everything else is just "playing" with layout and can be done easy by using existing (or 3rd party) components. Sometimes I really wonder how come there aren't more freeware solutions based on ExifTool. Maybe I should try to provoke: is GUI really that good? 

Bogdan

[pb]

In my limited experience, GUI programming is conceptually trivial, yet very difficult to get right.  The various toolkits that I have tried either give rather unprofessional results, or are extremely complex to program.  It's been some years, so maybe the situation has changed, but that's probably why no one is jumping into the fray.  (As an example, note all the difficulty you had with pipes a while back.)

Also,  if you want multi-platform applicability, it gets even trickier.

--peter

[BogdanH]

You're totally right. GUI as it is, is only one of possible variatons I've decided for. Basic idea was to work with ExifTool easier, but it should be capable to exploit ExifTool as much as possible -which is somewhat hard to combine (to please everyone).
Yes, it was pipes (and ExifTool's -stay_open option) that challenged me 

Bogdan