VistaDB 6.2 Released - A Further Optimized VistaDB
VistaDB 6.2 is now available for download! This update focuses on improving performance across the board, with changes that should help every user of our platform.
Performance is a quality VistaDB users want us to consider every update. It makes sense, as the database engine will have a dramatic effect on the overall performance of their applications, maybe even “make it or break it.” Additionally, as more applications move to constricted platforms like mobile phones, integrated devices, and more, performance optimization demands are higher than ever.
So with VistaDB 6.2, we wanted to make performance our focus. Help our users continue to get more while requiring less from their target platforms. Ultimately, this effort has taken shape in some major optimizations: a further improved locking system with multiple measures taken to reduce latency.
Why focus on performance measures for locking?
Every time a process even reads a row, the engine needs to make a lock. For example, a query that requires reading 1,000 rows may also require creating and releasing 1,000 locks. Creating a single lock doesn’t take long, but any inefficiency matters when creating and releasing hundreds of thousands of locks. The time adds up. Therefore, any way we can cut time off locking is worth considering for us.
This is why we have written quite a bit about locking, and why the headline changes each VistaDB release often revolve around our lock implementation. Locking happens so often during the regular operation of a database that it deserves all the work it can get. So, let’s take a look at how we’ve made locking more efficient for VistaDB 6.2:
Reduced Latency for All Locks
We have re-optimized the internal infrastructure for locking to reduce the latency when requesting or releasing a lock. The change affects both the Single-Process and Multi-Process modes. Specifically, it will have a high impact on queries where many rows are checked, like joins between larger tables.
The Multi-Process modes are limited in the improvements they may see compared to the Single-Process modes. The overhead of using file system locks is such that the gains from reduced latency may be overshadowed. But in some cases, the multi-process modes will still see performance benefits. For the Single-Process modes, because they use memory instead of the file system, the improvements should be significant.
New Locking Optimization for Single-Process Modes
We reduced latency for the Single-Process modes further by replacing the use of Mutex. We added Mutex in 6.1 to ensure atomicity/thread safety for the locking system, and for 6.2 have replaced it with interlocked operations. Interlocked operations are incredibly fast and atomic, meaning we do not need to worry about interruptions from other processes, making them effective for locking.
For a typical application, replacing Mutex with interlocked operations may be considered overkill. But the time it takes to engage and release a Mutex adds up when done hundreds of thousands of times. Let’s take a look at these test results on Windows using .NET 5:
| Locking Method | NS/iteration | Time to 1,000,000 Iterations |
|---|---|---|
| Mutex | 1587.448 | 1.587 seconds |
| Semaphore | 1574.152 | 1.574 seconds |
| SemaphoreSlim | 43.103 | 0.043 seconds |
| Interlocked | 13.140 | 0.013 seconds |
In this example and the other tests we performed, interlocked operations were much faster than our Mutex implementation from 6.1. So switching to interlocked operations should improve performance for all Single-Process mode users. But the change is most important for high volume workloads, high contention scenarios, where latency is a more considerable performance roadblock.
Performance Boost for Open Modes
We have made changes to the open modes to reduce processing time, specifically tests done while initiating a lock. When making a lock, our infrastructure runs a set of tests using overrides of virtual methods, each testing for different cases (null values, etc.). It was effective in that the testing covered every case necessary. Still, our implementation led to tests for conditions that are known upfront based on the open mode and storage object (i.e., table, index, row, etc.).
So, we rewrote the stack of overrides into a set of individual methods, each of which performed the same logic, but accounting for known conditions going in. This way, we can avoid tests that don’t apply and avoid re-testing. The result is a faster, cleaner testing process for the open modes, a better performing database for your application.
Try VistaDB 6.2 Today!
We’ve made additional changes for VistaDB 6.2 as well, including bug fixes for the VistaDBCommand.ExecuteScalar() method and for opening encrypted databases on certain .NET 6, .NET 5, and .NET Core systems.
If you are not a VistaDB user yet, you can try our most recent update in the product trial. For current eligible users, you can check out our release notes for additional details and download VistaDB 6.2 today!