This is done because the compiler is refusing to inline even after
adding inline hint.
- Get refvalues from directly from registers without using
`make_record`
compare_records_int
compare_records_string
compare_records_generic
comapre_records_generic will still be more efficient than compare-
_immutable because it deserializes the record column by column
I am currently working on upgrading Rust to the latest version
(https://github.com/tursodatabase/limbo/pull/1807). Initially, I wanted
to address all Clippy errors in that PR, but I decided to move them into
a separate one to make it easier to review.
**Note:** In the latest version of Clippy, it is considered an error to
place variables after a comma in string formatting macros (e.g.,
`format!`), rather than inside the `{}` placeholders. That's where most
of the errors are coming from.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1827
Although concurrency doesn't work yet (#2059), we do want to support
concurrency, and one good first step is not to make the simulator hang
forever once any connection gets a `Busy` result from the VDBE
Closes#2060
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2061
- Also added a benchmark for opening databases, the main thing that is
slowing `Database::open_file` is `parse_schema_rows`.
- `to_uppercase` was being called multiple times, leaving a relevant
mark on stack traces due to multiple allocations. `make_ascii_upper`
reuses the memory and is faster due to not handling unicode characters
(still compatible with sqlite).
- Do direct btree calls instead of creating a program for updating
`Schema` with `Schema::make_from_btree`.
- Faster type substr comparison using fixed size `u8` slices.
<img width="952" height="507" alt="image" src="https://github.com/user-
attachments/assets/0d0c52ff-05a1-431e-a93d-e333b53c0bb8" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2042
This inhibits ANSI color codes on non-TTY stdouts. It should fix logs
with mangled color codes such as
https://github.com/tursodatabase/turso/issues/2046.
## Result
On this branch:
<img width="1492" height="421" alt="image" src="https://github.com/user-
attachments/assets/1d281203-bda1-41c6-944e-f10dac16834e" />
If I don't pipe or redirect, on this branch, the color is displayed.
On main:
<img width="1496" height="438" alt="image" src="https://github.com/user-
attachments/assets/3844edac-dead-4655-96fb-df6ab5353021" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2052
Closes#2047
the validation code was assuming that:
- if the parent has overflow cells after inserting a divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit, so
it gets pushed to `parent.overflow_cells()`. Parent usable space does
not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the
inserted cell overflowed, and use that to find the left pointer and
assert accordingly.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2050
the validation code was assuming that:
- if the parent has overflow cells after a inserting divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit,
so it gets pushed to `parent.overflow_cells()`. Parent usable space
does not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the inserted
cell overflowed, and use that to find the left pointer and assert accordingly.
We can use `right_page_id` directly to perform the validation instead of
carrying a raw pointer around which might be invalidated by the time we
do the validation.
Closes#2036Closes#1991
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2038
