Thanks Joe for all of your amazing feedback! :-) Lots of great info here for me to evaluate. Thanks for taking the time to write such a detailed response!
--Dave -------------------------------- > At 1:18 PM -0700 4/18/06, Dave Wooldridge wrote: > >> (A) -- Use a REALdatabase file to store the folderitem's GetSaveInfo as one >> field and the folderitem's 4kb Thumbnail pic in another field (blob). When >> needing to load a specific thumbnail in the list, the DB is searched for the >> folderitem and when a match is found, pull the related thumbnail picture >> from the DB. > > This is nice and neat, provided you have a good way to convert a > picture to/from a string for storage in the database. Except, > perhaps, using GetSaveInfo as a key -- see below. > >> (B) -- Save the thumbnail as a small 4k image in a cache folder on disk, and >> then use a REALdatabase file to store the folderitem's GetSaveInfo as one >> field and the Thumbnail's folderitem GetSaveInfo as another field. When >> needing to load a specific thumbnail in the list, the DB is searched for the >> folderitem and when a match is found, use the related thumbnail folderitem >> data to go fetch the Thumbnail on disk and OpenAsPicture. > > This might be a problem, as described, since I don't think there's > any guarantee that the GetSaveInfo returned for a certain file > tomorrow will be the same as a GetSaveInfo string for it returned > today -- it may depend on what other files are mounted, the state of > file sharing, the phase of the moon, etc. I realize that this > affects both proposals, of course. > > I do think you're onto something here, though. You might consider > using the AbsolutePath of the image file as the lookup key with > either scheme. I know, I'm always saying never to use AbsolutePath, > but it may be justified in this case -- if the user does have two > volumes mounted with the same name, and an image has exactly the same > path on both, it's probably the same image anyway (since one volume > is most likely a backup copy of the other). So the thumbnail would > match both versions. > > Alternatively, you could compute an MD5 of the image file contents, > and use that to verify that it matches the cache (i.e., you'd store > the MD5 hash along with the thumbnail). This has the nice effect of > forcing your thumbnails to update if the images are changed -- which > may or may not be an issue in your case. > >> The advantage of method -A- is that it nicely contains the entire cache in >> one single DB file instead of a messy folder of thousands of small thumbnail >> images, but I worry that pulling a 4kb Picture out of a REALdatabase blob >> field could be slower than simply fetching a small 4kb >> folderitem.OpenAsPicture. > > Right, it probably would be. I'm not sure how much slower, though. > Personally, I'd just use individual files, because the database seems > like overkill for a simple cache -- most web browsers and email > clients cache images as individual files, so why not you too? > >> I know that Dictionaries are very fast, but if someone has an image >> collection of literally thousands of images, then loading an entire cache of >> thousands of thumbnails into a Dictionary into memory could require some >> seriously hefty RAM allocation. For example: 4kb x 10,000 images = 40 MB of >> RAM. > > Yeah, but on the other hand, it's only 40 MB of RAM. That's not very > much, and the VM system on any modern OS will cheerfully page out > most of that if it's not accessed in a while. If you really do need > this cache to be good only while the app is running, then I'd just do > that. > > If you want to limit the memory used (or provide an option to do so), > here's one approach: keep your cache in the form of an array, where > each entry has the FolderItem (or some key generated therefrom) and > the corresponding thumbnail. When you need a thumbnail, you scan > this array sequentially, until you find the right entry or exhaust > the array. When you find it, you pull it out of its position and > insert it at the top of the list, so it'll be found first next time. > If you don't find it, you create a new entry (and thumbnail), and > insert it at the top of the list, and delete the item at the other > end of the list if it's reached your limit. This way, > recently-accessed stuff stays near the top of the list, and stuff you > haven't needed in a while cycles out. > > Of course, this is exactly what VM does already, and it can probably > do a better job of it -- at the last WWDC I went to, the Apple > engineers were actually suggesting that you DON'T pull such tricks, > and instead just keep everything in memory and let VM sort it out. > But YMMV. > > HTH, > - Joe _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
