Ian Goddard wrote: > singhals wrote: >> Ian Goddard wrote: >>> singhals wrote: > %>< >>> >>> Easy. You only /copy/ them to the database. Don't delete the original. >>> >> >> Newbies don't think of /that/. They scan thru FTM and save where-ever >> it puts it. One copy, part of FTM. >> >>>> After the first few images were put in, most everyone discovered the >>>> database was growing exponentially, >>> >>> If that were really the case something would be wrong. It should just >>> grow linearly. >> >> You could be right, it's math after all, but 1 image tripled the file >> size on my test. 1, 300 dpi scan of a 2x3 B&W photo. > > That depends on the size of the file before you added the image. How > much bigger did the file grow in real terms. I'd expect it to grow by > the size of the image plus whatever else went in there by way of title > etc.& some indexing information. > IIRCC, it was under 1m before the first image. > There is an other factor, however. It may well be that it starts off > with a file of fixed size, mostly empty, adds data until it needs more > room and then adds another fixed extent. It could even be that each > time it keeps increasing the size of the extent ("They filled 4G? > Right, this time we'll add 8G. That should keep them quiet for a > while"). That's a good approach to space management; small databases > stay within an initial small allocation but large databases get a > generous allocation of space quickly and, provided there's a good sized > empty block from which they can take their extents, don't end up in many > scattered fragments which hurts performance. Each time the file extends > it does so exponentially but this is offset by extending less > frequently. In your case the acid test is what happens when you add a > few more scans. Do you get to the point where you can add another scan > or two without the file growing at all? Couldn't say. It grew and grew with each of 5 images I added, none particularly large by my standards. I booted the experiment after the 5th image. At which time, it was taking about 20 minutes to just OPEN the thing. Color me, peeved? > %>< >> >> (G) But, you see, users don't think like developers. Users see "Store >> images internally" and they think COOL! They don't think, "How many >> images can I get on a 7G HD?" > > 7G? When did I last see a 7G disk? The first thing I did with this > laptop was take out the 500G disk and drop in a 1Tb. Although in part > this was to enable the 2nd thing which was to install Debian Linux > without overwriting the original Win 7, just in case there was a problem > & I had to take it back. > > %>< >>> >>> AFAICS what Gramps was originally doing was to simply note the path& >>> filename of what you supplied. Only at export time did it take a copy. >>> That would mean if you reorganised what you though was an >>> outside-Gramps system it wouldn't have been able to find anything. >>> >>> BTW I installed the current version onto another Linux instance on a VM >>> & tried running the import again. It still has the same default >>> locations but will allow a merge. >>> >>> But I'd forgotten another of its little egregious features which is >>> still there. Each database has a name, e.g. 1881Census. But by the >>> time you've exported& reimported it's something like Family Tree 01 so >>> you have to go through the lot renaming them. >> >> Ooops? Can't you change the code for the default to echo the file-name? > > That would be possible given that it's open source but there's an awful > lot of Python code there so it was easier to just let it do its thing& > fix it afterwards than try to understand what needed fixing where, > especially as Python isn't one of my languages. I heard _that_. There comes a time when getting it done is more valuable than understanding it. (g) Cheryl