On Sun, 2024-07-28 at 00:14 +0200, Andreas Karlsson wrote:
> But even without that extra optimization I think this patch is worth
> merging and the patch is small, simple and clean and easy to
> understand
> and a just a clear speed up. Feels like a no brainer. I think that it
> is
> ready for
On 7/26/24 11:00 PM, Jeff Davis wrote:
Results (in ms):
"C" "libc_c" overhead
master:6350 7855 24%
v4-0001: 6091 6324 4%
I got more overhead in my quick benchmarking when I ran the same
benchmark. Also tried your idea with caching the last
On Thu, 2024-06-20 at 17:07 +0700, John Naylor wrote:
> On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote:
> > Attached is a patch to use simplehash.h instead, which speeds
> > things up
> > enough to make them fairly close (from around 15% slower to around
> > 8%).
>
> +#define SH_HASH_KEY(tb,
On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote:
> Attached is a patch to use simplehash.h instead, which speeds things up
> enough to make them fairly close (from around 15% slower to around 8%).
+#define SH_HASH_KEY(tb, key) hash_uint32((uint32) key)
For a static inline hash for speed
On 15.06.24 01:46, Jeff Davis wrote:
* instead of a hardwired set of special collation IDs, have a single-
element "last collation ID" to check before doing the hash lookup?
I'd imagine that method could be very effective.
