Performance of database and Date Book operations on the Tungsten T5 and Treo 650
Posted January 14, 2005
Here at Llamagraphics, we've been getting reports from some of our customers of unexplained slowdowns when running Life Balance on the PalmOne Tungsten T5 and Treo 650. Most often these were long time customers upgrading from prior devices who already had large numbers of records (more than 1000) in Life Balance and/or their Calendar. We suspected that these problems were due to the new non-volatile file system (NVFS) used on these devices, and decided to run some benchmarks to see where the slowdowns might be coming from and how we might work around them. The results were pretty interesting, so we thought we'd share them.
Our goals
Customers have been reporting that Life Balance is slow to exit on the T5 and Treo 650, especially if there are lots of records in the Calendar database. We have also had reports of timeouts during HotSync. Since Life Balance scans all of the Date Book records during HotSync, and in the background (during null events) when it is running, we suspected that something about our Date Book scanning code might be triggering the problem.
Life Balance uses the original Date Book database to access event records, while the built-in Calendar application on recent PalmOne devices uses a revised database that includes extended information. On these devices, a PalmOne compatibility layer allows third-party applications that access the older Date Book database to continue running. We wanted to compare the performance of the compatibility layer with direct access to the Calendar database.
Since PalmOne's white paper on NVFS suggests using DmGetRecord/DmReleaseRecord instead of DmQueryRecord, we also wanted to test the performance implications of that change.
What we tested
We began our tests with a 710 KB, 6800-record Date Book database provided to us by one of our customers. While this database is large by Palm standards, it is common for Life Balance customers to have large Date Book databases, and we thought it would be a more accurate test to use an actual customer database rather than synthetic data generated by Gremlins or some other source. We used Palm Desktop and Tungsten C/T5 simulators to convert this database to the new PalmOne Calendar database format.
The actual tests were run on a Tungsten C and a Tungsten T5. These devices both use Intel XScale processors at similar clock speeds, so benchmarks on the two devices should be comparable. We would also have liked to run the tests on a device that uses the new Calendar database but does not use NVFS, such as the Tungsten T3, but we didn't have a T3 available.
We ran three sets of tests. The first set was run on the Tungsten C using direct access to the Date Book database. The second set was run on the Tungsten T5 using direct access to the Calendar database. The third set was run on the Tungsten T5 using the Date Book compatibility layer to access the Calendar database.
Each test consisted of opening the database, processing records, and closing the database. We timed the opening and closing calls separately from the main operations since we suspected that closing the database was a significant performance bottleneck. The operations we tested were:
- Nothing
- Do nothing
- Query 1
- Call DmQueryRecord to get the middle record of the database
- Get 1 clean
- Call DmGetRecord followed by DmReleaseRecord(..., false) on the middle record of the database
- Get 1 dirty
- Call DmGetRecord followed by DmReleaseRecord(..., true) on the middle record of the database
- Query all
- Call DmQueryRecord repeatedly to get every record in the database
- Get all clean
- Call DmGetRecord followed by DmReleaseRecord(..., false) on every record in the database
- Get all dirty
- Call DmGetRecord followed by DmReleaseRecord(..., true) on every record in the database
- Get all dirty sync
- Call DmGetRecord, DmReleaseRecord(..., true) and DmSyncDatabase on every record in the database
Test results
Here are the raw test results. All times are measured in ticks (1/60 of a second).
| Tungsten C native | Tungsten T5 native | Tungsten T5 compatibility | |||||||
| Open | Process | Close | Open | Process | Close | Open | Process | Close | |
| Nothing | 0 | 0 | 0 | 0 | 0 | 48 | 11 | 0 | 117 |
| Query 1 | 0 | 0 | 0 | 0 | 0 | 34 | 10 | 1 | 67 |
| Get 1 clean | 0 | 0 | 0 | 0 | 0 | 37 | 10 | 0 | 90 |
| Get 1 dirty | 0 | 0 | 0 | 0 | 0 | 56 | 10 | 1 | 121 |
| Query all | 0 | 3 | 0 | 0 | 8 | 29 | 11 | 3,168 | 7,241 |
| Get all clean | 0 | 12 | 0 | 0 | 14 | 48 | 11 | 3,030 | 7,333 |
| Get all dirty | 0 | 12 | 0 | 0 | 14 | 50 | 10 | 2,967 | 23,442 |
| Get all dirty sync | 0 | 129,083 | 4 | 11 | 234,125 | 26,641 | |||
Observations
- DMGetRecord and DMRelease record are fast enough that there is no real reason not to switch to those routines in order to prevent DMHandles from being purged from memory on the NVMS devices.
- Closing a database under NVFS takes a significant amount of time regardless of how many records are accessed or modified. If your Palm OS application opens databases with large number of records, you may need to display a dialog to the user while closing the databases to let the user know what is happening. NVFS takes about 1 second per 10,000 records (on a T5) to close a database, even if no records were accessed or modified. This is very different from non-NVFS devices, which can close a database in under 1/60 of a second regardless of the number of records.
- While DMSyncDatabase() can speed up closing of the database, the performance hit to the running application is probably not going to save time unless you can do what you need to do with approximately three calls to DMSyncDatabase. DMSyncDatabase is taking about 19 ticks per call. So if you can group together many changes and sync them at once, that might be helpful in saving time when you close the database. DMSyncDatabase has no benefit when using the Date Book compatibility layer. (Don't go there.)
- The datebook compatibility layer is very slow, and applications that are using the Date Book compatibility layer to access the Calendar database to access more than a small number of records will need to be revised to use the Calendar directly. If you can access the Calendar database directly, customer experience will be improved significantly, and will be nearly as fast as on the Tungsten C.
- If you are using the Date Book compatibility layer, encouraging customers to purge the Calendar of old records may provide some immediate relief.
We hope this information is helpful to the Palm OS developer community, and benefits end users with NVFS devices. If you have comments on this white paper, please contact us at samalone@llamagraphics.com.