A collection of different transport implementations and related tools focused primarily on web technologies. Contains the implementations of 2 IETF RFCs (RFC6455, RFC7692), 1 formal specification (PostgreSQL) and several other invented ideas.

1. Client API Framework
2. Database Client
3. Database Object–Relational Mapping
4. Database Schema Manager
5. WebTransport Client/Server
6. Pool Manager

Embedded devices with a working heap allocator can use this no_std crate.

Many things that generally improve performance are used in the project, to name a few:

1. Manual vectorization: When an algorithm is known for processing large amounts of data, several experiments are performed to analyze the best way to split loops in order to allow the compiler to take advantage of SIMD instructions in x86 processors.
2. Memory allocation: Whenever possible, all heap allocations are called only once at the start of an instance creation and additionally, stack memory usage is preferably prioritized over heap memory.
3. Fewer dependencies: No third-party is injected by default. In other words, additional dependencies are up to the user through the selection of Cargo features, which decreases compilation times by a large margin. For example, you can see the mere 18 dependencies required by the PostgreSQL client using cargo tree -e normal --features postgres.

Since memory are usually held at the instance level instead of being created and dropped on the fly, it is worth noting that its usage can growth significantly depending on the use-case. If appropriated, try using a shared pool of resources or try limiting how much data can be exchanged between parties.

If you disagree with any of the mentioned charts, feel free to checkout wtx-bench to point any misunderstandings or misconfigurations.

There are mainly 2 things that impact performance, the chosen runtime and the number of pre-allocated bytes. Specially for servers that have to create a new instance for each handshake, pre-allocating a high number of bytes for short-lived or low-transfer connections can have a negative impact.

Anything marked with #[bench] in the repository is considered a low-level benchmark in the sense that they measure very specific operations that generally serve as the basis for other parts.

Take a look at https://bencher.dev/console/projects/wtx to see all low-level benchmarks over different periods of time.

Does not support systems with 16bit memory addresses and expects the infallible addition of the sizes of 4 allocated chunks of memories, otherwise the program will overflow in certain arithmetic operations potentially resulting in unexpected operations.

For example, in a 32bit system you can allocate a maximum of 2^30 bytes of memory for at most 4 elements. Such a scenario should be viable with little swap memory due to the likely triggering of the OOM killer or specific limiters like ulimit.