@ntcore-ts/client 1.0.0 → 1.1.0-beta.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +26 -9
  2. package/package.json +3 -2
package/README.md CHANGED
@@ -20,6 +20,16 @@ const gyro = ntcore.getDoubleTopic('/MyTable/Gyro');
20
20
  gyro.subscribe((value) => console.log(value));
21
21
  ```
22
22
 
23
+ The hot path (msgpack decode + shape check) is about **2.6 million frames/s** on an Apple M1 Pro (~0.4 µs per single-message frame). Typical FRC NT rates are tens to low thousands of updates per second.
24
+
25
+ ```mermaid
26
+ xychart-beta
27
+ title "Messages per second by frame size (Apple M1 Pro)"
28
+ x-axis ["1 msg/frame", "10 msg/frame", "100 msg/frame"]
29
+ y-axis "thousands of messages/s" 0 --> 16000
30
+ bar [2628, 10097, 14297]
31
+ ```
32
+
23
33
  ## Building
24
34
 
25
35
  Run `npm run build -w @ntcore-ts/client` (or `npx turbo run build --filter=@ntcore-ts/client`) to build the library.
@@ -34,18 +44,25 @@ Benchmarks measure how fast the client processes WebSocket messages. They are **
34
44
 
35
45
  **How to run**
36
46
 
37
- - From the repo root: `npm run bench`
38
- - From the package: `npx vitest bench --run` (in `packages/client`)
47
+ - From the repo root: `npm run bench` (client and React)
48
+ - From this package: `npm run bench -w @ntcore-ts/client`
39
49
 
40
50
  **What is measured**
41
51
 
42
- - **Tier 1 (hot path)**: Binary frame processing in isolation—decode (msgpack), schema parse, and callback. Benchmarks: one frame with 1, 10, or 100 messages.
43
- - **Tier 2 (mock WebSocket)**: End-to-end from mock server send to `onTopicUpdate` callback—WebSocket event → `onMessage` → `handleBinaryFrame` → callback.
52
+ - **Tier 1 (hot path)**: Binary frame processing in isolation—decode (msgpack), shape check, and callback. Benchmarks: one frame with 1, 10, or 100 messages.
53
+ - **Tier 2 (`onMessage`)**: 100 binary frames through `onMessage` → `handleBinaryFrame` → `onTopicUpdate`.
54
+
55
+ Both tiers use a mock server for the socket connection (no real NT server or robot). Results are reported as Hz (ops/sec), with min/max/mean and percentiles (e.g. p99).
56
+
57
+ **Findings** (Apple M1 Pro, Node 24)
44
58
 
45
- Both tiers use a mock server (no real NT server or robot). Results are reported as Hz (ops/sec), with min/max/mean and percentiles (e.g. p99).
59
+ | Workload | Frames or batches/s | Mean | Messages/s |
60
+ | ------------------------------ | ------------------: | -----: | ---------: |
61
+ | 1 message / frame | 2.63M | 0.4 µs | 2.63M |
62
+ | 10 messages / frame | 1.01M | 1.1 µs | 10.1M |
63
+ | 100 messages / frame | 143k | 7.1 µs | 14.3M |
64
+ | 100 frames through `onMessage` | 16.1k | 63 µs | 1.61M |
46
65
 
47
- **Findings**
66
+ CI re-runs these benches on every PR and fails if throughput drops to half of `main`. See the [performance guide](https://ntcore.chrislawson.dev/guide/performance).
48
67
 
49
- - **Tier 1 (hot path)** on typical hardware: ~550k–875k single-message frames/sec; ~115k–146k frames/sec with 10 messages per frame (~1.15M–1.5M messages/sec); ~12k–16k frames/sec with 100 messages per frame (~1.2M–1.6M messages/sec). Mean latency per frame is in the **microseconds** (e.g. ~1.1 µs for one message, ~6–7 µs for 10, ~63–67 µs for 100).
50
- - **Tier 2 (mock WebSocket)** exercises the full path from mock send to `onTopicUpdate`; throughput is in the same order of magnitude as Tier 1 for batched frames.
51
- - **Conclusion**: For normal FRC/NetworkTables use (tens to low thousands of topic updates per second over the network), the client can process far more than real traffic. The bottleneck in practice is the **network** (latency, bandwidth) and the NT server, not this client’s message processing.
68
+ **Conclusion**: For normal FRC/NetworkTables use (tens to low thousands of topic updates per second over the network), the client can process far more than real traffic. The bottleneck in practice is the **network** (latency, bandwidth) and the NT server, not this client’s message processing.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ntcore-ts/client",
3
- "version": "1.0.0",
3
+ "version": "1.1.0-beta.2",
4
4
  "description": "TypeScript client for WPILib NetworkTables 4.1 protocol",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -25,13 +25,14 @@
25
25
  "build": "rm -rf dist && rollup -c rollup.config.mts",
26
26
  "test": "vitest run",
27
27
  "bench": "vitest bench --run",
28
- "lint": "eslint ."
28
+ "lint": "oxlint ."
29
29
  },
30
30
  "dependencies": {
31
31
  "@msgpack/msgpack": "^3.1.3",
32
32
  "isomorphic-ws": "^5.0.0",
33
33
  "protobufjs": "^8.8.0",
34
34
  "tslog": "^5.2.0",
35
+ "wpilib-struct": "^1.0.1",
35
36
  "zod": "^4.6.2"
36
37
  },
37
38
  "publishConfig": {