You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I bisected the range of the bump and it is: ca5de30
$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [64c0000c2a9385020e7f357711c0da3de4b03517] Merge branch 'topic/bbannier/update-update-changes' [skip CI]
git bisect good 64c0000c2a9385020e7f357711c0da3de4b03517
# status: waiting for bad commit, 1 good commit known
# bad: [7347a2be4188a7ec2b3b71cf620fd3e3267c78af] Merge remote-tracking branch 'origin/topic/robin/simplify-ast-tests'
git bisect bad 7347a2be4188a7ec2b3b71cf620fd3e3267c78af
# good: [0af29c57e43f1c1c17f888469d67849ff9200b5b] Add a new unit item `Block` that stores a sequence of subitems.
git bisect good 0af29c57e43f1c1c17f888469d67849ff9200b5b
# bad: [8bb969e1c4c7ca416c27d26fb1caa0c6e4d92dec] Simplify parsing of literals.
git bisect bad 8bb969e1c4c7ca416c27d26fb1caa0c6e4d92dec
# good: [a1f8334e85a9b7c843e2820542b8f82e94b34548] Merge remote-tracking branch 'origin/topic/robin/gh-1839-aggregate-if'
git bisect good a1f8334e85a9b7c843e2820542b8f82e94b34548
# skip: [a0b18dca4a426f972e0a0060a6a1f072b6fd00de] Refactor type parsing modes.
git bisect skip a0b18dca4a426f972e0a0060a6a1f072b6fd00de
# good: [96d6cb47a3c06cae81f23f32f986a9808f042841] Add mode for optimize types parsing.
git bisect good 96d6cb47a3c06cae81f23f32f986a9808f042841
# bad: [ca5de306a7c397c1d37aa7eb662dabafaa8ca26b] Optimize parsing for `bytes &size=N`.
git bisect bad ca5de306a7c397c1d37aa7eb662dabafaa8ca26b
# first bad commit: [ca5de306a7c397c1d37aa7eb662dabafaa8ca26b] Optimize parsing for `bytes &size=N`.
The timings for a hyperfine -r 3 'taskset -c 1 zeek -C -r ./quic-16-50mb-transfers.pcap Log::default_writer=Log::WRITER_NONE' run are as follows locally:
Commit 8bb969e also stands out as slow and wonder a bit about detail::expectBytesLiteral taking a hilti::rt::Bytes for literal instead of a string_view. Doesn't hilti::rt::Bytes result in a string allocation including potential memory allocation if the literal is large?
Turns out our improved error messages were adding additional overhead
because we were now constructing them through `fmt()` each time we
needed more data, independent of whether there was actually going to
be an error reported.
This adds a second version of `waitForInput()` that doesn't receive an
already prepared error message, but just returns false on error so
that the caller can throw itself.
Closes#1908.
As reported in the Zeek repo, a recent bump of Spicy regressed performance of pcap-quic-16-50mb.
zeek/zeek#3953 (comment)
I bisected the range of the bump and it is: ca5de30
The timings for a
hyperfine -r 3 'taskset -c 1 zeek -C -r ./quic-16-50mb-transfers.pcap Log::default_writer=Log::WRITER_NONE'
run are as follows locally:PCAP is available on the os-perf-1 host
/mnt/data/test_data/quic-16-50mb-transfers.pcap
.The text was updated successfully, but these errors were encountered: