Closed gschlager closed 10 months ago
Still, I wonder if we should cache the mapping of named parameters to parameter position within prepared statements.
Cache them how? If we start mapping C-strings to integers, that introduces a certain complexity that I'm not sure is worth the trouble. Also, I think the time spent on binding parameters might be not really siginificant when looking at total time of execution.
@gschlager I'm closing this issue for lack of follow through. If you want to act on it feel free to create a PR. Thanks!
That's fine. Currently it's not a high priority for me as I have a workaround, but when I have some free time I'm going to look into it.
I wanted to know how fast each type of parameter binding is, so I wrote a benchmark and compared it to the sqlite3 gem.
Here's the result:
Extralite array
This is the fastest if you can bind an existing array. It's slower when you need to create the array especially for binding.
Extralite regular
This is slightly slower than binding an array, but still very fast. If you can bind values directly in the order they are needed, use this.
Extralite index
Binding a hash with numbers as keys is 1.15x slower than binding arrays. I mostly implemented this because I wanted to know how much slower named parameters are.
Extralite named
Binding named parameters is the slowest. Mapping parameter names to the parameter position comes with overhead.
All those methods are a lot faster than the sqlite3 gem. Still, I wonder if we should cache the mapping of named parameters to parameter position within prepared statements. In theory that should make it roughly as fast as "extralite index", but I'm not sure if it's worth the effort. After all, if performance is key, there's no way around positional binding.