Benchmarks again (IMPORTED) #2

New issue

Open

opened 2026-04-02 23:00:08 +00:00 by firepear · 1 comment

firepear commented

2026-04-02 23:00:08 +00:00

Owner

Let's try this again, but this time as unit tests.

one for ConnRead
one for ConnWrite
one for GenIds

and don't try to make any thing concurrent or real-world-like. That's not the point of benchmarks.

Running strategy was go test -bench Benchmark -run XXX to run only benchmarks

Let's try this again, but this time as unit tests. - one for ConnRead - one for ConnWrite - one for GenIds and don't try to make any thing concurrent or real-world-like. That's not the point of benchmarks. Running strategy was go test -bench Benchmark -run XXX to run only benchmarks

firepear self-assigned this

2026-04-02 23:00:08 +00:00

firepear commented

2026-04-02 23:00:23 +00:00

Author

Owner

The impetus here is that I've been thinking that handling the byte slice that ConnRead use for the payload in a different way might be better.

It could be an improvement to allocate an array (not slice) of the exact size of plen, rather than allocating a small slice and growing it as more data comes in. Unless we already do this?

The impetus here is that I've been thinking that handling the byte slice that ConnRead use for the payload in a different way might be better. It could be an improvement to allocate an array (not slice) of the exact size of plen, rather than allocating a small slice and growing it as more data comes in. Unless we already do this?

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

firepear/petrel#2

No description provided.

Rows
Columns