mirror of
https://github.com/refraction-networking/uquic.git
synced 2025-04-06 21:57:36 +03:00
d9665c632e
Especially the sentPacketHistory linked list shows up in allocation profiles, since a new list element is allocated for every single packet we send. Using a pool for the receiving path, as well as for the frame sorter, is less critical, since we're tracking ranges there instead of individual packets / frames, but it doesn't hurt either. The other occurrences where we use a linked list (connection ID tracking and the token store) are used so rarely (a few times over the lifetime of the connection) that using a pool doesn't make any sense there.
6 lines
295 B
Markdown
6 lines
295 B
Markdown
# Usage
|
|
|
|
This is the Go standard library implementation of a linked list
|
|
(https://golang.org/src/container/list/list.go), with the following modifications:
|
|
* it uses Go generics
|
|
* it allows passing in a `sync.Pool` (via the `NewWithPool` constructor) to reduce allocations of `Element` structs
|