Discord embed looks dodgy

Describe the bug
Sending a series of links on Discord causes output on Slack that seems to miss a leading newline.
To Reproduce
Steps to reproduce the behavior:

Send https://youtube.com/ https://google.com/ https://discordapp.com/ on Discord
Look at Slack
If it doesn't work, send https://youtube.com/ https://google.com/ https://discordapp.com/ on Discord again
Look at slack

You might have to do it a second time because I think Discord unfurling is late.
Note that the first time those link appear in Slack, you will see Slack's unfurling — Slack's unfurling won't appear the second time because they only unfurl once per "recent conversation" (to prevent embeds spamming up your screen). To get around Slack's unfurl "spam protection", you can cache bust by appending something to the query string: https://youtube.com/?1
Expected behavior
Either have a newline, or don't send Discord embeds if they are only unfurl embeds.
Screenshots/debug logs

Environment (please complete the following information):
e9edbfc0, macOS
Additional context
Nothing of significance other than ShowEmbeds:
[discord]
[discord.mta]
Token="..."
Server="..."
RemoteNickFormat="{NICK}"
WebhookURL="..."
ShowEmbeds=true

[slack]
[slack.mta]
Token="..."
RemoteNickFormat="{NICK}"

Hm tried to reproduce this, but nothing happens on the slack side, tried sending multiple times.

@qaisjp still an issue ?

Um let me try and reproduce on latest master (can't now though)
To confirm you've tried cache busting, right?

No I haven't, but I couldn't produce it on the first message.

I can definitely reproduce this on 2d8f749
it only works after the first message (because discord has the embed cached)


Unable to locate 'afxres.h'.  Ensure you have installed the ATL/MFC component of Visual Studio. (Windows-2022 Image)

Description
While testing out the new windows-2022 image for a project.
I receive this error:
Starting package 1/101: atlmfc:x64-windows-static-release
Building package atlmfc[core]:x64-windows-static-release...
-- [OVERLAY] Loading triplet configuration from: D:\a\qBittorrent\qBittorrent\triplets_overlay\x64-windows-static-release.cmake
CMake Error at ports/atlmfc/portfile.cmake:7 (message):
  Unable to locate 'afxres.h'.  Ensure you have installed the ATL/MFC
  component of Visual Studio.
Call Stack (most recent call first):
  scripts/ports.cmake:140 (include)

Error: Building package atlmfc:x64-windows-static-release failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: atlmfc:x64-windows-static-release
  Vcpkg version: 2021-08-12-85ab112d5ee102bc6eac8cdbbfdd173a71374e04

Additionally, attach any relevant sections from the log files above.
Error: Process completed with exit code 1.

Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11
[ ] Windows Server 2016
[ ] Windows Server 2019
[X] Windows Server 2022

Image version and build link
Current runner version: '2.280.3'
Operating System
Microsoft Windows Server 2022
10.0.20348
Datacenter
Virtual Environment
Environment: windows-2022
Version: 20210819.7
Included Software: https://github.com/actions/virtual-environments/blob/win22/20210819.7/images/win/Windows2022-Readme.md
Image Release: https://github.com/actions/virtual-environments/releases/tag/win22%2F20210819.7
Virtual Environment Provisioner
<IP_ADDRESS>-master-20210816-1
Is it regression?
No response
Expected behavior
For ATL/MFC latest or even the spectre mitigation versions to be installed by default/picked up
Actual behavior
No response
Repro steps
Unsure....

Hello @xavier2k6 ,
Do you have a public repro steps or may be minimal project with repro?
It will help us to understand what packages exactly should be installed to resolve the issue

@maxim-lobanov
Link to repo:
https://github.com/xavier2k6/qBittorrent/tree/vcpkg_test
Here's the workflow file being used:
https://github.com/xavier2k6/qBittorrent/blob/7562ba7d98609fb9fe285b7484bec1a90c1c69f3/.github/workflows/ci_windows.yaml
Attached logs:
logs_1711.zip

FYI
When installing Visual Studio 2022 on my own PC, I noticed:
Under "Desktop development with C++" heading in Visual Studio 2022.
C++ MFC is not checked by default.
C++ ATL  is checked by default.
C++ MFC not being checked by default when being installed on image could be the issue!

@maxim-lobanov @dmitry-shibanov
Thank you both for your help, the inclusion of Microsoft.VisualStudio.Component.VC.ATLMFC.Spectre in Windows Server 2022 (20210901 update) PR https://github.com/actions/virtual-environments/pull/4004 resolved my issue & build completed successfully.
Closing, as resolved.


test: automated cases for smoke tcs tc1432 tc1231 tc1276 tc1382

Added automation tests for
TC1432 Withdraw - Send - Check Fee Default
TC1321 Transfer - Send - make Transfer
TC1276 Transfer - Send - Reject Transfer tx
Added check for link to TC1382 Withdraw - Send - Artifacts

@pcheremu could you please review the PR?
Thanks in advance

@abilevych could you please review the PR
Thanks in advance


PACKAGES: PAAS Engine Design

We can actually use protobufs for the storage layer.
BigQuery does this BTW..
Mongo DB
https://github.com/dataform-co/dataform/pull/542

Allows Protobufs to be stored in MongoDB as BSON (https://www.mongodb.com/blog/post/bson)
SQL template that respects the protobufs is needed
MongoDB can do CDC

Then what to do with the events  ?
A highly flexible stream processors that is configurable on the fly makes the system highly extensible.
Streams ETL and CDC, etc
https://www.benthos.dev/
https://github.com/Jeffail/benthos
Web IDE: https://github.com/benthosdev/benthos-lab

is WASM and so DRY
https://github.com/Jeffail/benthos/blob/master/cmd/tools/benthos_config_gen/main.go
config generator. Can also work off Protobufs to gen all docs and other things

Benthos transforms can be designed with the Web GUI, and tested, and then compiled (as WASM at runtime into the Vector runtime.
Vector is a Data change processor that is high perf ( RUST)
https://github.com/timberio/vector/pull/2341

Pluggable now with WASM just like Envoy is.
"Introduce plugin support to Vector, providing a way for users to add custom functionality to Vector. This RFC introduces
WASM plugins specifically, but we envision the possibility of other implementations that may reuse ideas from this RFC.
This RFC introduces Transforms and will be later amended with Source and Sink functionality."
TinyGO WASM compiler would be preferable !!!

https://github.com/facebookincubator/ent

Looks much more powerful in the long term
very high dev productivity
high support
Protobufs can be used to generate the schema using golang templates

The relations are then added by hand.

Hooks API, then makes the CDC redundant i think.

Can also gen those from the protobufs and send to nats
Can also do proper GraphQL subscriptions: https://github.com/pkapatsos-blinq/Magma/blob/master/symphony/graph/graphql/resolver/common_test.go

Code gen of GraphQL struct tags

https://github.com/facebookincubator/magma/blob/master/symphony/pkg/ent-contrib/entgqlgen/internal/todo/ent/schema/todo.go#L30

Integration to openconsensus

https://github.com/facebookincubator/magma/blob/master/symphony/graph/viewer/viewer.go#L20

authz is designed in

https://github.com/facebookincubator/magma/tree/master/symphony/graph/authz

PUB SUB Support

https://github.com/facebookincubator/magma/commit/8a49ea307471c0794054c31a5568233bdf50ea73

NATS
https://github.com/google/go-cloud/blob/master/pubsub/natspubsub/go.mod

Integration to openconsensus
Agnostic interface so can swap out if needed or run on cloud providers own PUB SUB

Hey!  I am doing some of the WASM/protobuf work over at Vector and would be happy to chat with you and help provide any pointers. :)

@Hoverbear Hey and its really nice to hear support from you :)
I better check if you offering advice or thinking about helping us actually integrate Vector into our Platform ? Dont want to take the whole arm when a hand if offered !
I read the docs and code of Vector. Best docs i have ever seen btw. Hats off to you and the team.
Uses i see for Vector

Logging agent that does filtering for privacy aspects
Metrics
CDC with NATS. Saw that Rust NATS is almost read.

We currently use TIDB CDC, but i think being able to configure the "router" of Vector at runtime is really useful. Reminds me of How we use Envoy for GRPC-Web and Authn and Authz
Using WASM ( like envoy now has btw ) to make it easy to extend for CDC

Kubernetes logging

We run on GCP, but will move to microk8 or lokomotive so we can run on our own Servers soon.

I can help a bit with integration of Vector if it's appropriate for you! :) @binarylogic did a lot of the docs!
It sounds like you've got the rest of things figured out pretty good! :) Are you setting up  a grafana/prometheus system for your metrics? Vector can use log_to_metric to automatically add metrics to naughty services through their logs.


Update Composer dependencies (2024-08-11-00-18)

Visual regression test passed!
View the visual regression test report


[Snyk] Security upgrade php from 8.0-apache to 8-apache

Snyk has created this PR to fix 2 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

modules/module-2/src/Dockerfile

We recommend upgrading to php:8-apache, as this image has only 84 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

CVE-2023-44487 SNYK-DEBIAN11-NGHTTP2-5953384
  561

Improper Encoding or Escaping of Output SNYK-DEBIAN11-APACHE2-7414113
  275

Improper Encoding or Escaping of Output SNYK-DEBIAN11-APACHE2-7414113
  275

Improper Encoding or Escaping of Output SNYK-DEBIAN11-APACHE2-7414113
  275

Improper Encoding or Escaping of Output SNYK-DEBIAN11-APACHE2-7414113
  275

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

🎉 Snyk hasn't found any issues so far.
✅ security/snyk check is completed. No issues were found. (View Details)
✅ license/snyk check is completed. No issues were found. (View Details)


spring-ai-qianfan unknown client id

Please do a quick search on GitHub issues first, there might be already a duplicate issue for the one you are about to create.
If the bug is trivial, just go ahead and create the issue. Otherwise, please take a few moments and fill in the following sections:
Bug description
按照springai官网的配置接入qianfan（spring-ai-qianfan-spring-boot-starter），调用以下接口报错
401 Unauthorized: "{"error_description":"unknown client id","error":"invalid_client"}"
我知道请求中缺少client id，但是不知道在哪里进行配置
Environment
@GetMapping("/ai/generate")
public Map generate(@RequestParam(value = "message", defaultValue = "Tell me a joke") String message) {
return Map.of("generation", chatClient.call(message));
}
Steps to reproduce
Steps to reproduce the issue.
Expected behavior
A clear and concise description of what you expected to happen.
Minimal Complete Reproducible example
Please provide a failing test or a minimal complete verifiable example that reproduces the issue.
Bug reports that are reproducible will take priority in resolution over reports that are not reproducible.

the client id is your app api key, check you application on: https://console.bce.baidu.com/qianfan/ais/console/applicationConsole/application/v1
you can create an app, get the api key and secret key.

and config the application.yml file, like this:
spring:
  ai:
    qianfan:
      apiKey: {your app api key}
      secretKey: {your app secret key}


Consumer Issues

Why is it that when "consumer.offset.reset.to" is set to "earliest", Flink will consume from the earliest offset instead of the submitted offset every time it is started,.

it seems be caused by #19 .


rm

Signed-off-by: Jakub Guzik<EMAIL_ADDRESS>

/retest

/override pull-prowtest-unit

@jmguzik: /override requires a failed status context or a job name to operate on.
The following unknown contexts were given:

pull-prowtest-unit

Only the following contexts were expected:

In response to this:

/override pull-prowtest-unit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/meow

@jmguzik:

In response to this:

/meow

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: jmguzik
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jmguzik: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

pull-prowtest-build
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-build

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/override pull-prowtest-build

@jmguzik: Overrode contexts on behalf of jmguzik: pull-prowtest-build

In response to this:

/override pull-prowtest-build

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/wip

/work-in-progress

/retest

@jmguzik: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

pull-prowtest-test
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-test

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@jmguzik: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

pull-prowtest-test
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-test

pull-prowtest-test-2
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-test-2

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@jmguzik: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

pull-prowtest-test
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-test

pull-prowtest-test-2
1f8611dc032f295ac7d55e1d1397911a3d5d056b
link
true
/test pull-prowtest-test-2

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Setup e2e tests with cypress

Hey @yubathom,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: e71e26e0-e617-11e9-82e3-2501c7641175

Hey @yubathom,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 3e0202b0-e61d-11e9-82e3-2501c7641175

Hey @yubathom,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: bb510fd0-e61e-11e9-82e3-2501c7641175

Hey @yubathom,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 7fa427f0-e61f-11e9-82e3-2501c7641175

Hey @yubathom,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 2489e6b0-e620-11e9-82e3-2501c7641175

Hey @yubathom,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 1aaf34f0-e621-11e9-82e3-2501c7641175

Hey @yubathom,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 72b38c30-e637-11e9-9927-991e8c29daea

Hey @yubathom,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 6bda4150-e63d-11e9-9927-991e8c29daea


Attributed string with justified aligmnet former than iOS 15 versions

I want to change foreground or background color of my search query string in full text with justified alignment. how can I achieve this property, please help

HairSpaceJustifiedText only works with String and I have no plans to add support for AttributedString as there is no easy way to measure the width due to the attributes that might affect the size of the characters.


[TRACKER] GridMap related issues

Gridmap:

[x] Cannot create a MeshLibrary for GridMap, either using ArrayMesh or procedural meshes #10118 (bug)
[x] GridMap does not work #9111 (bug)
[x] Cannot edit grids in the 3D viewport #10395 (bug)
[x] GridMap always visible even when set not visible #907 (bug)
[x] Add a get_used_cells() method like in TileMap #11857 (enhancement)
[x] Gridmap editor doesn't respects cell scale #10128 (bug)
[x] Duplication of tiles is broken in Gridmap #8812 (bug)
[x] Crash when Octant size is set to 0 #6515 (bug)
[x] Include transforms of tile object's children when generating .meshlib file #11722 (bug)
[x] GridMap does not convert collision data and it's not possible to define this data manually #11888 (bug)
[x] Freelook mode does not play well with Gridmap editor #10697 (bug/enhancement)
[x] Wrong UV mapping when atlasing enabled for 3D objects #6207  (enhancement)
[x] Pick up tile from map #3829 (enhancement)
[ ] Collision section of GridMap is outdated when compared to TileMap, (No collision Layers) #3284 (enhancement)
[x] Convert an arbitrary point in world space, to GridMap cell coordinates #11856 (enhancement)
[ ] A signal or callback for on_cell_changed() #11855 (enhancement)

More wide ones:

[x] Node Concepts for Module: Grid2D, Grid3D, HexGrid2D, HexGrid3D #10005 (discussion, feature request)

Postponed to 3.1:

[ ] More obvious way to rotate GridMap tiles #6639 (enhancement)
[ ]  Hide tiles when mouse hovering over them (to give ability to see how gridmap will look like after placing new tile) #5526 (enhancement)

(fell free to propose related issues, but note that I will moderate this thread in case of off-topics)

I've also been having issues adding collisions to the gridmap. It doesn't import any shapes and it does not let you change the number of shapes, in the shapes array, so I cannot add them manually.

@Giacom That seems to work correctly now

Still having the same issue. Collision boxes aren't being imported and I can't change the shapes array, trying to resize it immediately puts it back to 0.

@Giacom this deserves it's own issue. Please open new one, include detailed reproduction steps and sample project. Thank you

https://github.com/godotengine/godot/issues/11888
Done.

#907 is done, too.

About More obvious way to rotate GridMap tiles I think the current rotating is okay, but we need one more thing - flipping tiles, along with rotating.

#18836 should probably also be added to this.

#17118 probably should be part of this tracker.

#22205 top, as Vector3i would be very useful for GridMap.

Has there been any discussion about mirroring items in the GridMap? Is there enough free data in the structure for this, I imagine we'd only need a few bits

If the parent or some ancestor of a GridMap has visible = false, the GridMapis still shown. It only hides when setting its own visibleproperty to false. Maybe this is related to #907 .

Add #23104 to this tracker (and probably the already closed #24130 as well, for completeness' sake).


ghetto: Add ghetto plugin

ack https://github.com/coala/corobo/pull/66/commits/00a0ca3a6187e36f2469b21b7f3d3b3d781379c3

Thanks!

@rultor merge

@rultor merge

@meetmangukiya OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@meetmangukiya Done! FYI, the full log is here (took me 2min)


Hash table improvements for BytesRefHash

Description
Performance improvements for BytesRefHash which includes:

Remove the extra bit-mixer step (here) now that BytesRef uses a stronger hash function (here).
Use larger initial capacity (1 → 32) to avoid frequent resizing.
Use fingerprint to short-circuit equality checks during linear probing caused by collisions.
Re-organize hash table values to minimize the longest probe sequence length.
Refactor code to avoid unnecessary paths, branches, and defensive checks in the hot path.

Related Issues
Meta issue: #8710
JMH Benchmarks
These results indicate the time to perform 1 million add(...) operations with varying number of unique keys. These operations were repeated and interleaved between 20 hash tables in order to make caches less effective. The following implementations are being compared:

(A) is the baseline implementation.
(B) adds fingerprinting, avoids unnecessary paths, branches, and defensive checks.
(C) uses a faster hash function on top of (B).

Peak improvement

Key length
A
B
C

8 bytes
–
-33.32%
-37.47%

32 bytes
–
-34.55%
-49.00%

128 bytes
–
-21.58%
-63.92%

Whether or not to minimize the longest probe sequence length
The following implementations are being compared:

(A) CompactBytesRefHash which performs simple linear probing for inserts.
(B) ReorganizingBytesRefHash which re-organizes the hash table values during inserts to minimize the longest PSL.

(A) is simpler and marginally faster for insert-heavy workloads. It also packs 32-bits of fingerprint information which is 65,536 times of (B), but false positives are already rare with (B). On the other hand, (B) provides marginally faster worst-case lookups due to better use of CPU cache lines.
Benchmarks show no appreciable performance difference between (A) and (B) since the latency is dominated by the time to copy the key.

Check List

[ ] New functionality includes testing.

[ ] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@backslasht @dblock Need your inputs!

Please check the section "Whether or not to minimize the longest probe sequence length".
I'm suggesting (A) as it's simpler, and marginal lookup improvements in (B) are dwarfed by expensive "equals" check which compares two keys byte-by-byte. This isn't the case with ReorganizingLongHash where equality check simply meant comparing two longs.
I'm also suggesting to completely replace the existing BytesRefHash instead of keeping two implementations (like before). Regardless of our choice between (A) and (B), both are better across the board over the existing implementation.

What do you think?

@ketanv3 - Would the benefit of CPU cache lines applicable when large numbers of keys are used in ReorganizingLongHash and also assuming the keys arrive out of order. Considering that is the worst case would it still out perform CompactBytesRefHash?

Recency criteria (i.e. correlated adds) isn't considered for BytesRefHash; it made more sense for LongHash where similar timestamps across consecutive hits made that optimization possible. Only the PSL criteria is considered which makes CPU caches more effective. Performance should be similar no matter if keys arrive in or out of order.
Theoretically, ReorganizingBytesRefHash should perform better than CompactBytesRefHash for lookups at the slight expense of inserts. But another factor to consider is the difference in byte packing:

CompactBytesRefHash uses [32 fingerprint, 32 ordinal] bits.
ReorganizingBytesRefHash uses [1 discard, 15 PSL, 16 fingerprint, 32 ordinal] bits.

Since the number of fingerprint bits is more in (1) (over 65K times more), it's not a 1-1 comparison between the two. With the current byte-packing scheme, the performance is balanced between the two. But we can experiment with [1 discard, 7 PSL, 24 fingerprint, 32 ordinal] bits to see if this helps us helps us speed up lookups even more.

@backslasht Here's some follow up:
I wrote an alternative benchmark that highlights the overhead of "new inserts" and the improvement it brings to "subsequent lookups". I ran it for large table sizes (10K to 100K) interleaved across 50 hash tables.

Insert – time to insert N unique keys across all hash tables.
Lookup – time to lookup those N unique keys across all tables.

On average, pure inserts were 8.68% slower and pure lookups were 3.47% faster when re-organizing. Inserts were about 30% more expensive than lookups, so a key needs to be repeated at least 4 times for the lookup improvements to compensate for the insertion overhead.
Note: Take these numbers with a grain of salt; I faced a lot of variance while benchmarking these large tables.

Thanks @ketanv3 for the experiments.
I think we can go with CompactBytesRefHash for the below reasons.
Given the number of operations for each key is going to be 2 (1 insert and 1 lookup), the benefit CompactBytesRefHash provides during insertion is marginally better than the benefit ReorganizingBytesRefHash provides during the lookup. Also, implementation wise,  CompactBytesRefHash is relatively simpler when compared to ReorganizingBytesRefHash.

Given the number of operations for each key is going to be 2 (1 insert and 1 lookup) ...

@backslasht
This isn't fully true; let me explain why. Several hits may produce the same key, so during aggregation, the BytesRefHash::add(key) method will simply return the ordinal of the key when it was first added (i.e. a lookup). In other words, the number of buckets should be much less than the number of hits (i.e. lookups >> inserts) for re-organization to be effective.
To summarise:

Inserts are always more expensive.
For small tables (< 10K keys), lookups are identical as the worst-case PSL isn't too high to begin with.
For large tables, lookups perform better and may compensate for the extra overhead of inserts if keys are repeated enough times.

This presents me with an idea: what if we re-organize only when the table grows? It will give us a permutation that sits between simple linear probing and Robin Hood hashing.

Thanks for the detailed explanation @ketanv3
I agree, it boils down to size of the table and the number of repeated keys where ReorganizingBytesRefHash performs marginally better. Looking at the additional complexity and very marginal benefits ReorganizingBytesRefHash brings, it makes sense to stick to CompactBytesRefHash and revisit ReorganizingBytesRefHash in future when compelling use case arise.

@dblock Would like to know your thoughts too.

@dblock Would like to know your thoughts too.

I am a bit out of my depth here - would love to see you and @backslasht agree on what should be a mergable state of this PR, first. If you need someone to break a tie I can give it a try for sure!

@backslasht @dblock Ready for review!

@reta @backslasht
Here's a detailed performance analysis of portable, fast, non-cryptographic hash functions from well-known libraries: Zero-Allocation-Hashing, xxhash-java, and hash4j.
Comparison between variants of xxHash

xxh3 performs better with small inputs (suitable for hash tables), but xxhash64 performs better with large inputs (suitable for digests).
The construction of xxhash64 makes it very unstable on small inputs (sawtooth pattern).
lz4 library's implementation performed poorly, even worse than the baseline for key length less than 256 bytes.
Using VarHandles was about 15% slower for small keys and up to 40% slower for large keys.
OpenHFT's xxh3 implementation internally uses Unsafe to access pre-defined constants even when we specify a VarHandle based accessor. It defeats the purpose of using VarHandles. :(

Winner: xxh3; assuming the internal usage of Unsafe is removed.
Comparison between other "safe" hash functions

FarmHash (successor to CityHash) has the best performance on small inputs, closely followed by wyhash. Due to their construction differences, the former's performance drops in steps, while the latter's performance drop is more gradual when the key length increases.
MetroHash and xxhash64 have the best performance on keys > 1000 bytes in size, closely followed by FarmHash and wyhash.

Winner: FarmHash and wyhash
Comparison between variants of wyhash

The difference between OpenHFT's Unsafe and VarHandle was marginal (not sure why?).
Hash4J's implementation performed better for keys < 1000 bytes, but slightly worse on larger keys. This was due to slight differences in their implementation: the former eagerly short-circuits on smaller keys.

Winner: Hash4J
Komihash
This is a relatively new hash function featuring both high large-block hashing performance and a high hashing throughput for small inputs, mainly designed for hash-tables. It is close to the class of hash functions like wyhash, so identical performance is not surprising.

Latency benchmarks
The raw performance results can be misleading, especially on small inputs. It may seem that the baseline is 2x faster than FarmHash for 1 byte keys, but it would only result in an overhead of 4 ms per 1 million keys hashed. Here's how the latency improvements scale with input size.
Latency improvement to hash 1 million keys wrt input size:

1 byte = -4 ms
10 bytes = 2 ms
100 bytes = 18 ms
1000 bytes = 323 ms
10,000 bytes = 3490 ms

Summary
I found FarmHash, wyhash, and komihash to have suitable performance for use in a hash-table. They are simple in construction, instruction-cache friendly, portable, and fast on small inputs, and second best on large inputs. They are well-known hash functions that produce an avalanche effect, so I haven't tested their quality (i.e. collisions in the hash table).

Here's a detailed performance analysis of portable, fast, non-cryptographic hash functions from well-known libraries: Zero-Allocation-Hashing, xxhash-java, and hash4j.

Thanks @ketanv3 , very comprehensive and educating analysis, I am wondering we you still have the measure data to check the GC allocation activity (if you don't, not a big deal).  Regarding  hash4j/komihash, OpenNFT/FarmHash, OpenNFT/wyhash, I think we would need to collect a bit more data regarding GC allocations (OpenNFT is notoriously good at not generating too much garbage).

Hi @reta, here a comparison of "gc.alloc.rate.norm" at different input lengths. The baseline/lz4 hash functions have significantly higher allocations, but between OpenHFT and Hash4J it's a tie. Despite, the absolute values for all of them are quite low for GC to be a concern.

Key length (bytes)
1
10
100
1000
10,000
100,000
1,000,000

BASELINE_MURMUR3
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.001 B/op
0.008 B/op
6.987 B/op

LZ4_XXHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.001 B/op
0.011 B/op
9.350 B/op

OPENHFT_UNSAFE_XXHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.001 B/op
0.016 B/op

OPENHFT_VH_XXHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.021 B/op

OPENHFT_UNSAFE_XXH3
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁴ B/op
≈ 10⁻⁴ B/op
0.004 B/op
0.030 B/op

OPENHFT_VH_XXH3
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.001 B/op
0.006 B/op
0.052 B/op

OPENHFT_UNSAFE_FARMHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.021 B/op

OPENHFT_VH_FARMHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.003 B/op
0.025 B/op

OPENHFT_UNSAFE_WYHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.003 B/op
0.025 B/op

OPENHFT_VH_WYHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁴ B/op
≈ 10⁻³ B/op
0.004 B/op
0.036 B/op

HASH4J_WYHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.019 B/op

OPENHFT_UNSAFE_METROHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.016 B/op

OPENHFT_VH_METROHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.021 B/op

HASH4J_KOMIHASH
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁵ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.003 B/op
0.028 B/op

Detailed results
Benchmark                                 (length)                    (type)   Mode  Cnt          Score   Error   Units
HasherBenchmark.hash                             1          BASELINE_MURMUR3  thrpt       431216932.362           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1                LZ4_XXHASH  thrpt       330014143.816           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1                LZ4_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1     OPENHFT_UNSAFE_XXHASH  thrpt       356146972.517           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1         OPENHFT_VH_XXHASH  thrpt       361550764.360           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1       OPENHFT_UNSAFE_XXH3  thrpt       362517217.608           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1           OPENHFT_VH_XXH3  thrpt       308650535.422           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1   OPENHFT_UNSAFE_FARMHASH  thrpt       414706582.955           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1       OPENHFT_VH_FARMHASH  thrpt       362075878.766           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1     OPENHFT_UNSAFE_WYHASH  thrpt       319224865.838           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1         OPENHFT_VH_WYHASH  thrpt       251163875.798           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1             HASH4J_WYHASH  thrpt       280432773.588           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1             HASH4J_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1  OPENHFT_UNSAFE_METROHASH  thrpt       402462682.598           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1      OPENHFT_VH_METROHASH  thrpt       402794095.943           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                             1           HASH4J_KOMIHASH  thrpt       308433387.242           ops/s
HasherBenchmark.hash:·gc.alloc.rate              1           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm         1           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                   1           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10          BASELINE_MURMUR3  thrpt       165928443.039           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10                LZ4_XXHASH  thrpt        98241270.644           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10                LZ4_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10     OPENHFT_UNSAFE_XXHASH  thrpt       222250745.208           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10         OPENHFT_VH_XXHASH  thrpt       201486146.939           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10       OPENHFT_UNSAFE_XXH3  thrpt       308233732.333           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10           OPENHFT_VH_XXH3  thrpt       296493552.032           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10   OPENHFT_UNSAFE_FARMHASH  thrpt       362454196.630           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10       OPENHFT_VH_FARMHASH  thrpt       335258629.956           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10     OPENHFT_UNSAFE_WYHASH  thrpt       280608602.911           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10         OPENHFT_VH_WYHASH  thrpt       251031410.701           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10             HASH4J_WYHASH  thrpt       198398155.527           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10             HASH4J_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10  OPENHFT_UNSAFE_METROHASH  thrpt       363568879.806           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10      OPENHFT_VH_METROHASH  thrpt       366733256.941           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                            10           HASH4J_KOMIHASH  thrpt       212411823.010           ops/s
HasherBenchmark.hash:·gc.alloc.rate             10           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm        10           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                  10           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100          BASELINE_MURMUR3  thrpt        24412760.198           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100                LZ4_XXHASH  thrpt        13923693.388           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100                LZ4_XXHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100     OPENHFT_UNSAFE_XXHASH  thrpt        78942271.072           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                 100     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100         OPENHFT_VH_XXHASH  thrpt        57975705.231           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100       OPENHFT_UNSAFE_XXH3  thrpt        74353793.399           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                 100       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100           OPENHFT_VH_XXH3  thrpt        28697894.516           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100   OPENHFT_UNSAFE_FARMHASH  thrpt        73226144.398           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                 100   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100       OPENHFT_VH_FARMHASH  thrpt        44348674.229           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100     OPENHFT_UNSAFE_WYHASH  thrpt        74397608.690           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                 100     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100         OPENHFT_VH_WYHASH  thrpt        61213495.155           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100             HASH4J_WYHASH  thrpt        62217422.870           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100             HASH4J_WYHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100  OPENHFT_UNSAFE_METROHASH  thrpt        80774927.209           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁶            B/op
HasherBenchmark.hash:·gc.count                 100  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100      OPENHFT_VH_METROHASH  thrpt        59612073.855           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                           100           HASH4J_KOMIHASH  thrpt        62388568.318           ops/s
HasherBenchmark.hash:·gc.alloc.rate            100           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm       100           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                 100           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000          BASELINE_MURMUR3  thrpt         2641530.951           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count                1000          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000                LZ4_XXHASH  thrpt         1950350.868           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000                LZ4_XXHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count                1000                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000     OPENHFT_UNSAFE_XXHASH  thrpt        13797005.908           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000         OPENHFT_VH_XXHASH  thrpt        10322823.622           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000       OPENHFT_UNSAFE_XXH3  thrpt         6864043.270           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count                1000       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000           OPENHFT_VH_XXH3  thrpt         3514982.212           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count                1000           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000   OPENHFT_UNSAFE_FARMHASH  thrpt        10389486.389           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000       OPENHFT_VH_FARMHASH  thrpt         8540986.010           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000     OPENHFT_UNSAFE_WYHASH  thrpt         8766748.497           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000         OPENHFT_VH_WYHASH  thrpt         6183439.653           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count                1000         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000             HASH4J_WYHASH  thrpt         9216714.569           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000  OPENHFT_UNSAFE_METROHASH  thrpt        13470756.395           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000      OPENHFT_VH_METROHASH  thrpt         9974233.797           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                          1000           HASH4J_KOMIHASH  thrpt         7876511.726           ops/s
HasherBenchmark.hash:·gc.alloc.rate           1000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm      1000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁵            B/op
HasherBenchmark.hash:·gc.count                1000           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000          BASELINE_MURMUR3  thrpt          264342.060           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000          BASELINE_MURMUR3  thrpt               0.001            B/op
HasherBenchmark.hash:·gc.count               10000          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000                LZ4_XXHASH  thrpt          192029.154           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000                LZ4_XXHASH  thrpt               0.001            B/op
HasherBenchmark.hash:·gc.count               10000                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000     OPENHFT_UNSAFE_XXHASH  thrpt         1467219.028           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000         OPENHFT_VH_XXHASH  thrpt         1114350.191           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000       OPENHFT_UNSAFE_XXH3  thrpt          742912.428           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000           OPENHFT_VH_XXH3  thrpt          418142.305           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000           OPENHFT_VH_XXH3  thrpt               0.001            B/op
HasherBenchmark.hash:·gc.count               10000           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000   OPENHFT_UNSAFE_FARMHASH  thrpt         1093804.089           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000       OPENHFT_VH_FARMHASH  thrpt          907504.667           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000     OPENHFT_UNSAFE_WYHASH  thrpt          900050.555           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000         OPENHFT_VH_WYHASH  thrpt          628603.646           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻³            B/op
HasherBenchmark.hash:·gc.count               10000         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000             HASH4J_WYHASH  thrpt         1176294.898           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000  OPENHFT_UNSAFE_METROHASH  thrpt         1450232.278           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000      OPENHFT_VH_METROHASH  thrpt         1091811.359           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                         10000           HASH4J_KOMIHASH  thrpt          814040.287           ops/s
HasherBenchmark.hash:·gc.alloc.rate          10000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm     10000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴            B/op
HasherBenchmark.hash:·gc.count               10000           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000          BASELINE_MURMUR3  thrpt           26407.129           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000          BASELINE_MURMUR3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000          BASELINE_MURMUR3  thrpt               0.008            B/op
HasherBenchmark.hash:·gc.count              100000          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000                LZ4_XXHASH  thrpt           20039.520           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000                LZ4_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000                LZ4_XXHASH  thrpt               0.011            B/op
HasherBenchmark.hash:·gc.count              100000                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000     OPENHFT_UNSAFE_XXHASH  thrpt          147137.201           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000     OPENHFT_UNSAFE_XXHASH  thrpt               0.001            B/op
HasherBenchmark.hash:·gc.count              100000     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000         OPENHFT_VH_XXHASH  thrpt           91316.844           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000         OPENHFT_VH_XXHASH  thrpt               0.002            B/op
HasherBenchmark.hash:·gc.count              100000         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000       OPENHFT_UNSAFE_XXH3  thrpt           75025.788           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000       OPENHFT_UNSAFE_XXH3  thrpt               0.004            B/op
HasherBenchmark.hash:·gc.count              100000       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000           OPENHFT_VH_XXH3  thrpt           42235.044           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000           OPENHFT_VH_XXH3  thrpt               0.006            B/op
HasherBenchmark.hash:·gc.count              100000           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000   OPENHFT_UNSAFE_FARMHASH  thrpt          109000.657           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000   OPENHFT_UNSAFE_FARMHASH  thrpt               0.002            B/op
HasherBenchmark.hash:·gc.count              100000   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000       OPENHFT_VH_FARMHASH  thrpt           80675.458           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000       OPENHFT_VH_FARMHASH  thrpt               0.003            B/op
HasherBenchmark.hash:·gc.count              100000       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000     OPENHFT_UNSAFE_WYHASH  thrpt           90445.165           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000     OPENHFT_UNSAFE_WYHASH  thrpt               0.003            B/op
HasherBenchmark.hash:·gc.count              100000     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000         OPENHFT_VH_WYHASH  thrpt           61120.201           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000         OPENHFT_VH_WYHASH  thrpt               0.004            B/op
HasherBenchmark.hash:·gc.count              100000         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000             HASH4J_WYHASH  thrpt          117452.179           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000             HASH4J_WYHASH  thrpt               0.002            B/op
HasherBenchmark.hash:·gc.count              100000             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000  OPENHFT_UNSAFE_METROHASH  thrpt          141840.739           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000  OPENHFT_UNSAFE_METROHASH  thrpt               0.002            B/op
HasherBenchmark.hash:·gc.count              100000  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000      OPENHFT_VH_METROHASH  thrpt          106486.878           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000      OPENHFT_VH_METROHASH  thrpt               0.002            B/op
HasherBenchmark.hash:·gc.count              100000      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                        100000           HASH4J_KOMIHASH  thrpt           81106.395           ops/s
HasherBenchmark.hash:·gc.alloc.rate         100000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm    100000           HASH4J_KOMIHASH  thrpt               0.003            B/op
HasherBenchmark.hash:·gc.count              100000           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000          BASELINE_MURMUR3  thrpt            2621.827           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000          BASELINE_MURMUR3  thrpt               0.014          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000          BASELINE_MURMUR3  thrpt               6.987            B/op
HasherBenchmark.hash:·gc.count             1000000          BASELINE_MURMUR3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000                LZ4_XXHASH  thrpt            1959.188           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000                LZ4_XXHASH  thrpt               0.014          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000                LZ4_XXHASH  thrpt               9.350            B/op
HasherBenchmark.hash:·gc.count             1000000                LZ4_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000     OPENHFT_UNSAFE_XXHASH  thrpt           13881.544           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000     OPENHFT_UNSAFE_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000     OPENHFT_UNSAFE_XXHASH  thrpt               0.016            B/op
HasherBenchmark.hash:·gc.count             1000000     OPENHFT_UNSAFE_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000         OPENHFT_VH_XXHASH  thrpt           10569.369           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000         OPENHFT_VH_XXHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000         OPENHFT_VH_XXHASH  thrpt               0.021            B/op
HasherBenchmark.hash:·gc.count             1000000         OPENHFT_VH_XXHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000       OPENHFT_UNSAFE_XXH3  thrpt            7270.184           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000       OPENHFT_UNSAFE_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000       OPENHFT_UNSAFE_XXH3  thrpt               0.030            B/op
HasherBenchmark.hash:·gc.count             1000000       OPENHFT_UNSAFE_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000           OPENHFT_VH_XXH3  thrpt            4248.382           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000           OPENHFT_VH_XXH3  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000           OPENHFT_VH_XXH3  thrpt               0.052            B/op
HasherBenchmark.hash:·gc.count             1000000           OPENHFT_VH_XXH3  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000   OPENHFT_UNSAFE_FARMHASH  thrpt           10363.610           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000   OPENHFT_UNSAFE_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000   OPENHFT_UNSAFE_FARMHASH  thrpt               0.021            B/op
HasherBenchmark.hash:·gc.count             1000000   OPENHFT_UNSAFE_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000       OPENHFT_VH_FARMHASH  thrpt            8637.606           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000       OPENHFT_VH_FARMHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000       OPENHFT_VH_FARMHASH  thrpt               0.025            B/op
HasherBenchmark.hash:·gc.count             1000000       OPENHFT_VH_FARMHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000     OPENHFT_UNSAFE_WYHASH  thrpt            8749.859           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000     OPENHFT_UNSAFE_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000     OPENHFT_UNSAFE_WYHASH  thrpt               0.025            B/op
HasherBenchmark.hash:·gc.count             1000000     OPENHFT_UNSAFE_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000         OPENHFT_VH_WYHASH  thrpt            6069.568           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000         OPENHFT_VH_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000         OPENHFT_VH_WYHASH  thrpt               0.036            B/op
HasherBenchmark.hash:·gc.count             1000000         OPENHFT_VH_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000             HASH4J_WYHASH  thrpt           11403.889           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000             HASH4J_WYHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000             HASH4J_WYHASH  thrpt               0.019            B/op
HasherBenchmark.hash:·gc.count             1000000             HASH4J_WYHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000  OPENHFT_UNSAFE_METROHASH  thrpt           13705.780           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000  OPENHFT_UNSAFE_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000  OPENHFT_UNSAFE_METROHASH  thrpt               0.016            B/op
HasherBenchmark.hash:·gc.count             1000000  OPENHFT_UNSAFE_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000      OPENHFT_VH_METROHASH  thrpt           10280.255           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000      OPENHFT_VH_METROHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000      OPENHFT_VH_METROHASH  thrpt               0.021            B/op
HasherBenchmark.hash:·gc.count             1000000      OPENHFT_VH_METROHASH  thrpt                 ≈ 0          counts
HasherBenchmark.hash                       1000000           HASH4J_KOMIHASH  thrpt            7807.204           ops/s
HasherBenchmark.hash:·gc.alloc.rate        1000000           HASH4J_KOMIHASH  thrpt              ≈ 10⁻⁴          MB/sec
HasherBenchmark.hash:·gc.alloc.rate.norm   1000000           HASH4J_KOMIHASH  thrpt               0.028            B/op
HasherBenchmark.hash:·gc.count             1000000           HASH4J_KOMIHASH  thrpt                 ≈ 0          counts

Thanks @ketanv3 for the detailed benchmarking exercise, this is very insightful.
Overall, I see FarmHash, Wyhash, and Komihash having similar performance and heap allocation.
I'm leaning towards Komihash for reasons below:

Based on the numbers in https://github.com/avaneev/komihash
It is under active development which indicates the performance may get better with time.

I'm leaning towards Komihash for reasons below:

Side with @backslasht here, thanks @ketanv3

@backslasht @reta I'm more inclined towards FarmHash for the following reasons:

Usually, the published performance results are misleading; they talk about the raw performance on large inputs (digests) but not about the performance on very small inputs (hash table keys). Each hash function has a startup cost (irrespective of the input size) and an incremental cost (proportional to the input size). For use in a hash table, we want a hash function that has a tiny startup cost, an acceptable incremental cost, and an instruction cache-friendly code. One way to gauge is to look out for cycles/hash on small keys.
Another big factor is the language itself; komihash for example, requires an unsigned multiplication of two 64-bit numbers. Since Java doesn't support unsigned longs, we end up performing a chain of operations to get the desired result, which could be more expensive than other languages which support it natively. For this reason, the fastest C++ hash function may not be the fastest in Java (ignoring the platform differences).

There's another fast hash function out there: https://github.com/erthink/t1ha. Unfortunately, there's no Java port available. Seems like it too depends on fast unsigned multiplication of two longs (https://github.com/OpenHFT/Zero-Allocation-Hashing/issues/23).
FYI, I'm running benchmarks with the short-listed hash functions when used in a hash table. It should holistically answer for both quality and performance. Early results favour FarmHash, but I'll let it complete fully. :)

Hi @reta @backslasht, here's the performance within the hash table.
I ran the experiments with a subset of arbitrarily chosen key lengths with growing table sizes. As expected, since all hash functions have an avalanche effect, the impact of collisions was negligible and the performance was mainly driven by the performance of the hash function.
Short keys
For keys less than 30 bytes, FarmHash has the best performance.

Medium keys
For keys between 30 and 100 bytes, FarmHash performs better on small tables but wyhash performs better on large tables.

Large keys
For keys larger than 100 bytes, wyhash has the best performance followed by komihash. The difference was significant compared to FarmHash.

Summary
I'm impressed by the performance of wyhash/komihash on large inputs, and I expect their performance to get better on small inputs once we enforce the minimum version to JDK 18+ where unsignedMultiplyHigh can be replaced with Math.unsignedMultiplyHigh which has x86_64 and aarch64 intrinsics.

Thanks @ketanv3  for the experiment.
Based on the results, it is clear that farmhash is out of the options. Between komihash and wyhash, I'm still leaning towards komihash but open for wyhash as well. I'll let you decide between them.

@reta @backslasht
Out of curiosity, I decided to write my own Java port of t1ha hash function. The results are shockingly good!
Raw performance
It's faster all around—faster than FarmHash on small inputs and wyhash/komihash/xxh3/MetroHash on long inputs. Unlike FarmHash where performance drops in steps, here it's more gradual as the input length increases.

Allocations
Here's a summary of "gc.alloc.rate.norm" at different input lengths. One of the best again.

Key length (bytes)
1
10
100
1000
10,000
100,000
1,000,000

T1HA
≈ 10⁻⁶ B/op
≈ 10⁻⁶ B/op
10⁻⁶ B/op
≈ 10⁻⁵ B/op
≈ 10⁻⁴ B/op
0.002 B/op
0.015 B/op

Hash table performance
Performance at arbitrarily chosen key lengths with growing table sizes. t1ha performed best in all tests.

Caveats
The above results seem too good to be true; so are there any trade-offs? Yes. To overcome language and performance limitations, my implementation differs slightly from the reference implementation in C++, so the returned values will vary.
But does it matter? Probably not. For our use-case, all we need a fast hash function that achieves avalanche. Here's how my implementation compares to other well known hash functions:
Avalanche statistics on 50-byte random input
For context, smhasher considers a hash function to pass the avalanche test if the bias is less than 1% (here). It can be seen how poorly the inbuilt Arrays.hashCode is defined.

Sum of squared errors
Bias
Diffusion

XXH3
0.64
0.0065%
99.9935%

FarmHash
0.87
0.0052%
99.9948%

wyhash
0.64
0.0015%
99.9985%

komihash
0.65
0.0028%
99.9972%

t1ha
0.64
0.0056%
99.9944%

Arrays.hashCode
2852.51
16.2308%
83.7692%

Avalanche diagram
Here's a comparison between Arrays.hashCode and t1ha's avalanche diagram. It shows the probability of an output bit flipping (y-axis) when a single input bit (x-axis) is flipped. Ideally, we want to be close to 0.5 to achieve avalanche.

Repeated the experiment with 24, 32, 40, 48, 56, 64, 72, 80, 96, 112, 128, 160, 512, 1024-bit keys (as defined in smhasher) and was able to achieve avalanche every time. Let's roll this out?

@ketanv3 - The results looks great! Any considerations on the maintainability of the java port?

Any considerations on the correctness and maintainability of the java port?

I don't expect the returned values to match the reference implementation in C++ due to slight differences in my implementation to overcome the language limitations. We'll be explicit about these caveats in the implementation so it's not mistaken for the original implementation.
We'll have tests to verify the quality of the returned values, using sum of squared errors and bias metrics. It's worth pointing out that, in a hash table, improvements to a hash function's quality has diminishing returns. A 64-bit hash value will be modded with the table size (which is usually pretty small), and birthday paradox ensures that collisions happen no matter how good the hash function is, as long as it's not completely flawed.

I don't expect the returned values to match the reference implementation in C++ due to slight differences in my implementation to overcome the language limitations. We'll be explicit about these caveats in the implementation so it's not mistaken for the original implementation.

I feel uneasy about this statement: definitely not an expert on hash functions but the implementors spend a lot of time on developing those, so I would feel much more comfortable when ours and reference implementation matches (even when charts look good)

I'm impressed by the performance of wyhash/komihash on large inputs, and I expect their performance to get better on small inputs once we enforce the minimum version to JDK 18+ where unsignedMultiplyHigh can be replaced with Math.unsignedMultiplyHigh which has https://github.com/openjdk/jdk/pull/5933 and https://github.com/openjdk/jdk/pull/8840 intrinsics.

Does your t1ha implementation rely on that as well? What JDK version we use to run these tests?

@reta I understand your concern; I too would have preferred to match the reference implementation if our use-case was fingerprinting where we would have used all 64 bits of the hash value. But in a hash table, where the hash value is modded with the table size, we lose a lot of entropy anyways and collisions are unavoidable (for dynamic workloads). Creating a perfect hash function is impractical and resolving collisions in an open-addressed table is often cheaper.
Here's the explained by experts from this field:

https://news.ycombinator.com/item?id=19359504
https://news.ycombinator.com/item?id=19358799 (answered by rurban who maintains the smhasher fork).

The only requirement is that the hash function isn't fundamentally flawed; which I have verified using the avalanche tests. I have also included them as part of unit-tests.
Yes, t1ha also requires unsignedMultiplyHigh and that's where my implementation differs. I'll push my code, that'll make things more clear.

Yes, t1ha also requires unsignedMultiplyHigh and that's where my implementation differs. I'll push my code, that'll make things more clear. The results I've shared on this PR are using OpenJDK 17.

:+1. thanks @ketanv3

Looks good to me. Thanks @ketanv3 for all the experiments and the PR.

Second that, I think I understood the idea behind BytesRefHash (it is too clever :D) but it looks pretty good, the numbers in particular are convincing, thanks @ketanv3

@ketanv3 could you please run `./gradlew spotlessApply'

@ketanv3 could you please run `./gradlew spotlessApply'

@reta Thanks for pointing out! I was wondering why this didn't fail in my local workspace (I try to run precommit before pushing anything to remote). Just learnt that the precommit GH action runs on top of what's already present in the main branch (which totally makes sense), and some recent commits made spotless checks stricter. Learnt something new today!
Have updated it now. Should be passing. :)

@dblock @nknize do you folks want to take a look?

On top of the encoding improvements (#9412), this change would further reduce the latency by a decent amount. These tests in particular have pretty small composite keys (< 20 bytes), but improvements would be larger for larger keys.

Test
p50 before
p90 before
p50 after
p90 after

PR #2687 / mix
4023 ms
4185 ms
3857 ms
4024 ms

PR #2687 / numeric
538 ms
591 ms
485 ms
530 ms

OSB / http_logs / multi_term_agg
2241 ms
2282 ms
2102 ms
2147 ms

Hi @dblock, can you take a look now? Thank you!

I have made these minor changes. Please review the diff. Thank you!

Thanks @ketanv3 , it looks reasonable, I also see that the same optimization is present in the current BytesRefHash (over int-based hashes).

Looks good to me! thanks @ketanv3

Hi @dblock, did you get a chance to review this?


Potential memory leak detected by Valgrind

What is the issue you have?
I encountered a weird memory leak in my code, when returning nlohmann::json object from my function, if function returning the object (of any type) throws then 32 bytes are leaked.
This only happens on GCC, doesn't happen on Clang.

Please describe the steps to reproduce the issue. Can you provide a small but working code example?
Code:
json-valgrind.cpp

#include <nlohmann/json.hpp>

int throw_error()
{
  throw std::runtime_error("leak memory");
}

nlohmann::json minimal_leak()
{
  return {{"leak", throw_error()}};
}

int main()
{
  try {
    minimal_leak();
  } catch(...) { }
  return 0;
}

build:
g++ json-valgrind.cpp -o json-valgrind -g -O0

run:
valgrind ./json_valgrind

What is the expected behavior?
Valgrind exits saying that definitely lost: 0 bytes in 0 blocks

And what is the actual behavior instead?
Valgrind exits saying that definitely lost: 32 bytes in 1 blocks

Which compiler and operating system are you using? Is it a supported compiler?
Tested on Manjaro Linux with:

GCC 9.1.0
GCC 8.3.0
Ubuntu 18.04 Docker container with GCC 7.4.0

Did you use a released version of the library or the version from the develop branch?
Tested with release 3.7.0 and 3.5.0

I wonder if this is nlohmann/json bug or GCC bug, since it doesn't happen on Clang

I don't think this call even hits any code from this library.  The difference between the versions can be explained by the fact that the order of parameter evaluation isn't guaranteed to be left to right.  My guess here is that GCC creates a std::string for "leak" and then doesn't clean it up when the exception is thrown, and Clang executes the function call first before creating the "std::string".
I suspect that you could reproduce this with this code that doesn't involve the json library:
int throw_error()
{
  throw std::runtime_error("leak memory");
}

std::pair<std::string, int> minimal_leak()
{
  return {{"leak", throw_error()}};
}

int main()
{
  try {
    minimal_leak();
  } catch(...) { }
  return 0;
}

@muttleyxd Did you have the chance to check https://github.com/nlohmann/json/issues/1713#issuecomment-526236090?

@gregmarr @nlohmann
Sorry for my late reponse
This:
#include <stdexcept>
#include <string>
#include <utility>

int throw_error()
{
  throw std::runtime_error("leak memory");
}

std::pair<std::string, int> minimal_leak()
{
  return {"leak", throw_error()};
}

int main()
{
  try {
    minimal_leak();
  } catch(...) { }
  return 0;
}

exits fine, saying that 0 bytes were lost
I tried doing something like
std::pair<std::pair<std::string, int>, std::pair<std::string, int>> minimal_leak()
{
  return {{"leak", 123}, {"leak", throw_error()}};
}

but it won't leak anything.


How to use font-awesome library in Flutter-app online as well as offline?

Question at stack overflow:
https://stackoverflow.com/questions/57956232/icons-not-rendering-in-flutter-app-how-to-use-font-awesome-library-in-flutter-a

Duplicate of #41096


STR-46 Enhance currency data

Define currencies and currency pairs in config.

Should this be closed and re-opened in Strata?


unordered "media" styles generation

Summary

tl;dr: follow the order of declaration on the config when generating media-bound styles (maybe even at top level)

although some might suggest not to have overlaps on media/breakpoints, i do find it confusing/breaking some web standards and best practices — for example mobile-first media queries usually just use min-width instead of a range (as it’s on stitches website)
To Reproduce
here’s a scenario where i’m having a hard time making it work:
media: {
  xs: '(min-width: 0px)',
  sm: '(min-width: 576px)',
  md: '(min-width: 768px)',
  lg: '(min-width: 992px)',
  xl: '(min-width: 1280px)',
}

also tried naming alphabetically, like bp1 – bp5, to no avail

codesandbox
look how we have some completely mixed media-query overrides: 576px → 0px → 768px

this should be a way simpler a version of my website’s grid overlay component (you can visit the site and right click the 🌞 🌔 button to show it)
Expected behavior
the styles would be output following the order i’ve written (0px → 576px → 768px on the aforementioned scenario)
System information

OS: macOS
Browser (if applies) chrome, safari and firefox
Version of Stitches<EMAIL_ADDRESS>Version of Node.js: v14.18.2

As a work around I found using the bp1 etc. rule did work for me, but what was bewildering was the breakpoint at 1600 didn't even exist?

for me it didn’t @joshuaellis 😢

:information_source: My suggestion was more of a workaround to have something working @vitordino. I closed the related issue because it makes no sense.
I'm waiting for reactions from stitches team there, as the issue has been sitting there for a while.
Any updates on your side?

yes this is something on the radar but gonna take some time of as it's a bit of an involved change that needs tons of testing


[Android] Notification Dot not showing up

Summary
Notification Dot is not showing up on app icon.
Environment Information

Device Name: OnePlus 6
OS Version: 9
Mattermost App Version: 1.16.1
Mattermost Server Version: NA

Steps to reproduce
How can we reproduce the issue?
When a user sends you a message and app is running in background, notification dot is not showing on app icon.
Show Notification Dot is enabled in app settings
Expected behavior
When a push notification is received and app is running in background , notification dot should appear on app icon.
Observed behavior
No notification dot shows up.

Possible fixes
If you can, link to the line of code that might be responsible for the problem.

Hi @ajdev6, would you happen to know your Mattermost server version? You would normally find the information from Mattermost settings > About this App section.

Hi @ajdev6, would you happen to know your Mattermost server version? You would normally find the information from Mattermost settings > About this App section.

5.7.0

Hi @ajdev6,
Letting you know that this is not a bug as the badges on Android are only available on certain devices. Android officially added support for 8.0+ https://developer.android.com/training/notify-user/badges.
Would you like to share this idea on our feature request forum here: https://mattermost.uservoice.com/forums/306457-general?

Hi @amyblais,
I am testing on OnePlus 6 on Android 9. It supports notification badge. I have diagnosed the issue.
The issue is with mattermost-server payload.
I checked with the server payload in this file https://github.com/mattermost/mattermost-push-proxy/blob/master/server/push_notification.go
We need to update it according to the following docs:
https://firebase.google.com/docs/cloud-messaging/android/receive#sample-receive
https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages
Its not a feature request. The shortcutBadger is already implemented in react native notifications module.
Hope this helps!

Hi @ajdev6, our developers said that this is a new thing that we have never added support for. Only some devices have had this feature.

Hi @ajdev6, letting you know that we've opened an improvement ticket for this here: https://mattermost.atlassian.net/browse/MM-14467. There is no need to open a feature request issue as we can track this via the Jira ticket. Thanks for reporting this!

@ajdev6 can you help clarify what is missing in the payload?

Letting you know that the Jira ticket was closed since this is not supported yet.
Please share this idea on our feature request forum here: https://mattermost.uservoice.com/forums/306457-general.


Edited "DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION Parameters" section.

Added the first analysis action.

@tedhudek - This PR looks good and is ready to go to master/live, I will review the others.


ngFormBuilder and ng2-formio

Can I use JSON-Objects generated by ngFormioBuilder within ng2-Formio?

Yes you can. All of our libraries maintain a consistent JSON format.