Thyrfing:
There are several variables that can affect perceived or actual performance of a database. Important variables: the Preferences settings on how to import and store certain file types.
Let’s talk about images, for example. I’m going to ignore mere external linking (File > Link To) in this discussion. (The discussion also applies to PDF files.)
[1] Preferences > Images > Link to originals. Example: Importing a JPEG image 6456 KB in size results in a new database file that’s 36 KB in size. The full image file is stored in the Finder, external to the database package.
[2] Preferences > Images > Copy files to database folder. Example: Importing a JPEG image 6456 KB in size results in a new database file that’s 36 KB in size. The full image file is copied into the database Files folder, and also remains stored in the Finder, external to the database package.
[3] Preferences > Images > Copy file into database. Example: Importing a JPEG image 6456 KB in size results in a new database file that’s 6456 KB in size. The full image file is copied into the database ‘body’, and also remains stored in the Finder, external to the database package.
Now if I import 100 images of that size into my database, I should expect a significant difference to show up in the package size of my database, depending on whether I’ve used import method [1] above (the minimum size growth), or import method [2] or [3] above (significant package size increase). That’s pretty obvious. Let’s say my database size (not package size) is (approximately) 5 GB for option [3] and less than 1 GB for import options [1] or [2].
But what about differences in the performance of the database, depending on the import method used. Should I expect differences? The answer is yes, but there are variables affecting that answer. The most important variable is the amount of free RAM that I’ve got when I launch the database.
Case 1: I’ve got 8 GB RAM and the database size is roughly 5 GB (if I used import option [3]), or less than 1 GB for import options [1] or [2] . I’ve got plenty of RAM “headroom” so that I can load the entire database into RAM and in this case I won’t see much performance difference between any of the 3 import options above. The important point is that I won’t need much Virtual Memory use (in the form of swap files requiring disk access). But, needless to say, most of us don’t have 8 GB RAM!
Case 2: I’ve got the same database size conditions as in Case 1, but I’ve only got 500 MB RAM. Oops! I’m going to start using Virtual Memory (and building up HD disk swap files) pretty fast as I access images, and that’s going to happen a lot more for the database created using import option [3]. So I would expect to see more performance deterioration for the database created using import option [3].
Caveat A: Don’t take my numbers too seriously. Just very rough approximations.
Caveat B: It’s really more efficient to import items directly into the database body, because the the other options result in a ‘pointer’ document that then requires disk access to pull up the desired image. But that concept of efficiency assumes no limitations of physical RAM; and as a practical matter, available free physical RAM is something most of us just don’t have enough of.
Bottom line: There are always trade-offs, depending on what one wants to do. It’s up to the user.
If I want my database to be highly portable between computers, I import images, PDFs and unknown file types into my database Files folder, so that the files will be available if I move the database to another computer (or run it off a portable FireWire drive or even a CD). That’s the option [2] approach. My database package file can become very large, but the database body remains relatively compact.
Most of the time, I leave my digital camera photos in the Finder, so that I have lots of options, including importing some or all into my iPhoto library, or doing digital editing of the original photos under other applications. Sometimes I will import a few photos into my DT Pro database using import option [1]. That sacrifices portability of the database, but can be useful for other purposes, e.g., creating a Web site using DT Pro File > Export > As Website.
I rarely use the import option [3] to import photos directly into the database body.