BenedictRESEARCH / NOTES
AutoCAD
The faster answer was local
Could I send a calculation out of a live drawing session and return an answer AutoCAD would actually use?
The answer has to get back into the drawing
A standalone worker returning a number is not enough for a CAD user. The drawing is still open, the application has its own state, and the result has to arrive in the form the host expects. I used AutoCAD to test that part of the problem, rather than only benchmarking arithmetic outside an application.
I explored two operations: curve length and intersections. I generated drawings I could inspect and compare against the original implementation. That gave me controlled tests, but not a representative collection of student or professional drawings.
Curve length worked—and was much too cheap to move
The restricted length path returned remotely calculated values through an ordinary LIST command without calling the intercepted native length function again. Later tests returned eight results across three drawings. Curved and weighted cases that disagreed with the original calculation stayed on the native path.
The useful lesson was the timing. Successful intercepted calls took roughly 570 ms at the median, while the worker’s arithmetic and the native calculations were much smaller. I had demonstrated that the host could consume a remote result, not that moving this calculation was worthwhile.
Intersections gave me more work to compare
I next tested route intersections that produced 16,384 and 65,536 crossing points. Before integrating them into the live host, I measured the same captured inputs through local and remote Rust paths.
With compressed replies, the smaller bridge test took about 9.4 ms locally and 857 ms remotely. The larger took about 34.7 ms locally and 1.24 seconds remotely. Compression helped the remote path, but the equivalent local routine was still far ahead. Those bridge timings excluded application capture and result installation.
Then I returned the arrays into live AutoCAD
The live intersection experiment produced five remote returns that the host consumed without repeating the native calculation. I also stopped the worker: the application fell back to its original calculation and returned the correct array. Remote consumption resumed after recovery.
That did not erase the failures. Some exchanges failed or timed out; the first encounter with an unfamiliar geometry pair still performed a comparison against the original implementation. Reversed inputs and later direct-interface checks had to be investigated separately.
Measuring the operation a user actually waits for
I eventually compared the original implementation, an in-process local Rust path and the remote path using the same complete-operation timer. It included lookup, computation, the exchange where relevant, conversion of the returned array and writing the result to a binary file.
For 16,384 crossings, the original operation took about 3.97 seconds, warm local execution 123 ms and warm remote execution 1.04 seconds. At 65,536 crossings, the corresponding figures were 66.1 seconds, 297 ms and 845 ms. This was an implementation improvement, but local—not remote—was the faster way to use it.
These are small, sequential tests: one original sample at each size, three local samples and two or three remote samples. One local run at the smaller size took 1.21 seconds. The medians do not make that variation disappear.
Why I would not hand this to students yet
The warm numbers leave out an important first-use problem. A previously unseen large geometry pair took about 57.6 seconds for the local path to establish its comparison with the original. A user still waits almost a minute for that first answer.
The later eight-case direct-interface checks made me more confident about the supported behaviour, including prefixes, reversed operands and changes in document state. But there is still no complete CAD installer, clean second-machine installation or representative drawing evaluation. A working integration is not yet a usable student product.
Technical details and evidence
The host was AutoCAD 2021. Curve-length work investigated AcGeCurve3d::length; intersections used ActiveX IntersectWith through the official GeometryOverrule. The live intersection result does not qualify an ordinary interactive intersection command or arbitrary spline geometry.
The November 10 complete-operation native baselines have one sample each. Local warm medians use three samples; remote uses two and three. Sessions were sequential, not randomized. A 1,209.915 ms local outlier remains in the smaller test.
Returned coordinates were compared with native enumeration against a 1.25e-11 budget. Cold comparison, API-only timing, bridge timing and full export are different boundaries. The four-entry session cache remembers exact comparisons, not result coordinates; document lifecycle changes invalidate it.
The November 11 direct SDK checks covered eight cases. All observed native statuses were zero, leaving nonzero native-error behaviour untested. The campus assessment remains NO-GO.
Reading remote curve lengths on three different drawings
Technical details and evidence
- Experiment identifier
- cad-length-crossdrawing-r1
- Original title
- Cross-drawing curve lengths consumed remotely, first campaign
- Measurement boundary
- Six live remote returns across three independently created and pinned drawings, each geometry first qualified against the native implementation on a separate command. Ordinary LIST commands. Demonstrates host acceptance on more than one drawing; it is not a speed comparison and not a student workload.
- Hardware
- Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.
- Software
- AutoCAD 2021 R24.0.47.0.0; Rust release build of the curve primitive and its bridge.
- Input
- Three independently generated pinned drawings with unit-weight degree-1 geometry. Original lengths 7, 14 and 21; three-dimensional edited lengths 10.211102550927979, 16 and 22.416407864998739.
- Samples
- 6 live remote returns, one per geometry state, plus a separate native qualification command for each of the six.
- Statistical method
- single sample per return
- Cold / warm state
- Warm for the six returns; each exact geometry was qualified on a separate command first.
- Network
- Encrypted tunnel to the CPU node. Every successful return was a fresh worker request, not a cached result substitution; 17 worker requests were verified against worker identifiers and timings.
- Serialization
- Application frames 194 bytes for the request and 51 bytes for the successful reply.
- Correctness checks
- All six returns made zero intercepted native calls and matched the analytic reference at the unchanged 1e-10 tolerance with a 1.25e-11 comparison budget. Weighted and curved cases on the third drawing stayed native on measured disagreement.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| remote hook, first drawing original geometry | 566.7866 ms | 1 | single sample |
| remote hook, first drawing edited geometry | 2119.9736 ms | 1 | single sample |
| remote hook, second drawing original geometry | 511.6534 ms | 1 | single sample |
| remote hook, second drawing edited geometry | 572.8415 ms | 1 | single sample |
| remote hook, third drawing original geometry | 2168.865 ms | 1 | single sample |
| remote hook, third drawing edited geometry | 4759.4218 ms | 1 | single sample |
Experimental limitations
- Single sample per return.
- Median successful hook time was 569.81405 ms against native calibration in the microsecond range, so this is not acceleration.
- Terminal lockout: an identical copy at an unpinned path stays native and interception does not resume in that process, which is an explicit student-experience limitation.
- No independent review of the larger remote-execution difference was performed.
- Three incompatible cases deliberately stayed native and are recorded separately.
The host consumed remote lengths on three different drawings without falling back to native, which is stronger evidence than a single-drawing result. The transport cost still dominates the native compute cost, so the value here is correctness, not speed.
Technical details and evidence
Compressing the intersection reply and repeating the whole test
Technical details and evidence
- Experiment identifier
- cad-intersection-bridge-compressed-r2-128
- Original title
- Captured-array intersection bridge, lossless-compressed run r2, 16384 crossings
- Measurement boundary
- The same captured-array measurement as the uncompressed run, repeated in a separate second run with a lossless compressed response encoding. Bridge wall time only; excludes host capture, native qualification and result installation.
- Hardware
- Windows workstation for the local placement (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1 for the remote placement.
- Software
- Rust release build of the intersection primitive and its bridge with the compressed response codec; arrays captured earlier from AutoCAD 2021 R24.0.47.0.0.
- Input
- 128 owned integer orthogonal route pairs producing 16384 intersection points; request payload 8226 bytes.
- Samples
- 3 repeats per placement. Local bridge wall 9.9361, 9.2408 and 9.4044 ms. Remote bridge wall 856.7324, 1703.9614 and 819.2004 ms.
- Statistical method
- median of 3 repeats
- Cold / warm state
- Warm: the same captured array and worker session were reused.
- Network
- Remote placement used an encrypted tunnel to the CPU node, where the worker spent a median 5.330 ms; the local placement worker spent a median 2.713 ms.
- Serialization
- Compressed run: request 8226 bytes, compressed response frame 24555 bytes, uncompressed response payload 262179 bytes and decoded payload 262169 bytes. The frame digest is recorded and matches the uncompressed run's payload digest.
- Correctness checks
- Maximum per-point difference against the captured native array was 1.8190449138500806e-12 against a 1.25e-11 comparison budget, identical to the uncompressed run. The response digest was identical for local and remote placement and identical to the uncompressed run.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| equivalent local rust bridge, median wall | 9.4044 ms | 3 | median of 3 samples |
| remote bridge over encrypted tunnel, median wall | 856.7324 ms | 3 | median of 3 samples |
CALCULATED FROM THE MEASUREMENTSequivalent local rust bridge, median wall ÷ remote bridge over encrypted tunnel, median wall = 0.010977057×9009.9103% higher time for remote bridge over encrypted tunnel, median wall.
Experimental limitations
- Bridge wall time only; excludes host capture, native qualification and result installation.
- No application process was running.
- Synthetic owned integer geometry, not a student drawing.
- 3 repeats per placement, sequential, on one workstation and one remote node.
- Workstation CPU model not recorded.
- This is a separate run from the uncompressed one and the two must be quoted as distinct runs, not merged.
Compressing the response shortened the remote bridge wall substantially while the decoded payload and the numerical result stayed identical. The local bridge also moved slightly, so the compression effect is visible on the remote path and not cleanly isolated from run-to-run variation.
The same remote acceptance at 65,536 crossings, including a recovery
Technical details and evidence
- Experiment identifier
- cad-intersection-live-nov10-warm-256
- Original title
- Live intersection consumption, warm 65536-crossing returns and worker recovery
- Measurement boundary
- The same live geometry-overrule path with the larger fixture. The second case follows a stopped remote worker and shows the remote path resuming after recovery. API and export times are separate boundaries and are not compared with each other.
- Hardware
- Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.
- Software
- AutoCAD 2021 R24.0.47.0.0; the owner-approved intersection adapter build; Rust release build of the intersection primitive and its bridge.
- Input
- Owned integer orthogonal route fixture, 256 routes (65536 crossings).
- Samples
- 2 live remote returns, one per case.
- Statistical method
- single sample per case
- Cold / warm state
- Warm for both returns; the recovered case reused the qualification established before the worker was stopped.
- Network
- Encrypted tunnel to the CPU node; remote worker compute was 22579 and 23356 microseconds.
- Serialization
- Compressed response frame 55545 bytes for the 65536-crossing case against a 1048611-byte uncompressed payload.
- Correctness checks
- Both returns matched the native enumeration within 1.25e-11 with a maximum original-order difference of 7.30437932361383e-12, and no native call was made on either return.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| API time, warm return | 2266 ms | 1 | single sample |
| full export time, warm return | 28625 ms | 1 | single sample |
| API time, return after worker recovery | 1469 ms | 1 | single sample |
| full export time, return after worker recovery | 32484 ms | 1 | single sample |
Experimental limitations
- Single sample per case.
- Synthetic owned route geometry, not a student drawing.
- Not an ordinary interactive command path.
- Export totals include enumeration, formatting and disk output.
- The native baseline for this fixture comes from a different session and is not a matched pair with these returns.
The larger case behaves like the smaller one: the application consumes a remote array without a native call, and the remote path resumes after the worker is restored. The remaining cost is transport and output formatting, not computation.
What the first use of a drawing costs in each mode
Technical details and evidence
- Experiment identifier
- cad-campus-nov10-cold-qualification
- Original title
- First-use cost of a geometry snapshot in local and remote modes
- Measurement boundary
- The complete-operation cost of the first use of an exact geometry snapshot in local mode and in remote mode, where the application must establish the ordering and status semantics natively before a remote result can be accepted. Sessions were sequential and each figure is a single sample.
- Hardware
- Windows workstation (CPU model not recorded); remote CPU node with 8 cores, 31331228 KiB available memory and 209 GB free disk running Ubuntu 26.04.1.
- Software
- AutoCAD 2021 R24.0.47.0.0; local candidate adapter build with an in-process Rust primitive; frozen remote adapter build.
- Input
- Owned integer route pairs at 128 and 256 routes.
- Samples
- 4 cold complete-operation samples: local 16384 at 3437.6661 ms, remote 16384 at 4938.6445 ms, local 65536 at 57597.9075 ms, remote 65536 at 63164.2667 ms.
- Statistical method
- single sample per case
- Cold / warm state
- Cold by definition: each case is the first use of that snapshot in its session, so the native qualification runs.
- Network
- Local mode ran with no worker and no tunnel. Remote mode used the encrypted tunnel and the bounded forwarding proxy.
- Serialization
- As in the matched comparison measurements.
- Correctness checks
- Every cold case produced the complete array with the native output and status preserved, with a maximum original-order difference of 0.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| local cold complete operation, 16384 crossings | 3437.6661 ms | 1 | single sample |
| remote cold complete operation, 16384 crossings | 4938.6445 ms | 1 | single sample |
| local cold complete operation, 65536 crossings | 57597.9075 ms | 1 | single sample |
| remote cold complete operation, 65536 crossings | 63164.2667 ms | 1 | single sample |
CALCULATED FROM THE MEASUREMENTSlocal cold complete operation, 16384 crossings ÷ remote cold complete operation, 16384 crossings = 0.69607482×43.662716% higher time for remote cold complete operation, 16384 crossings.
CALCULATED FROM THE MEASUREMENTSlocal cold complete operation, 65536 crossings ÷ remote cold complete operation, 65536 crossings = 0.91187487×9.6641691% higher time for remote cold complete operation, 65536 crossings.
Experimental limitations
- Single sample per case; these are not statistically qualified figures.
- The native baselines for the same fixture vary between sessions, so the difference between the 65536-crossing local and remote cold figures is not a controlled result.
- First-use latency blocks the application and cancellation is not qualified.
- The earlier campaign's 65536-crossing remote first-use API time of 73265 ms is preserved separately and is not overwritten by these figures.
- A session-only cache of exact orderings removes repeated native work when alternating between drawings, but it does not remove the first cost.
- The campus verdict for this work is NO-GO for a student campus demonstration; nothing here is a student-readiness statement.
Session caching removes repeated native work when alternating between drawings, but the first use of an unseen drawing still costs about a minute at the larger size. That is the dominant usability problem and the main reason the verdict is negative.
Technical details and evidence
Eight interface cases designed to break the external path
Technical details and evidence
- Experiment identifier
- cad-sdk-direct-qa-8-cases
- Original title
- Direct application-interface differential qualification, eight cases
- Measurement boundary
- Eight differential cases executed directly against the application interface: the first exact pair, the same pair warm, a caller prefix, a duplicated prefix, a shifted operand that creates endpoint contacts, reversed operands cold and warm, and a document create-and-close followed by a return. Each case compares the complete native enumeration and coordinates, not only digests. Covers routing correctness and cache invalidation; it is not a performance measurement and the case timings are explicitly not benchmark figures.
- Hardware
- Windows workstation (CPU model not recorded).
- Software
- AutoCAD 2021 R24.0.47.0.0; test-build-only interface qualification command; Rust release build of the intersection primitive.
- Input
- Owned pinned 128-route fixture: 16384 intersections; the prefix cases returned 16385 and 16386 points; the shifted-operand case returned 18400 points.
- Samples
- 8 cases, one run each.
- Statistical method
- count of cases by outcome
- Cold / warm state
- Mixed: the first, reversed and post-document cases were cold and required native qualification; the warm cases reused a qualified snapshot.
- Network
- None: the local kernel path was used, so no worker and no tunnel were started.
- Serialization
- Not applicable; no transport frames were produced on this path.
- Correctness checks
- All eight cases returned status 0 and compared the complete native enumeration and coordinates. The warm cases matched the native ordering with a maximum original-order difference of 1.8189894035458565e-12 against the 1.25e-11 budget. The prefix cases preserved the caller's prefix and delegated natively. The shifted-operand case was rejected by the local kernel and fell back natively with the original array and status preserved. Creating and closing another document invalidated the cache and forced fresh qualification.
| Original metric | Exact value | Samples | Statistic |
|---|---|---|---|
| differential interface cases executed | 8 cases | 1 | count of cases |
| cases resolved by the local kernel with zero native calls | 2 cases | 1 | count of cases |
| cases delegated to the native implementation | 6 cases | 1 | count of cases |
| rust test suites passing in the same build | 74 cases | 1 | count of tests |
| native policy checks passing in the same build | 74 cases | 1 | count of checks |
Experimental limitations
- One run per case and one owned fixture; not representative student geometry.
- All observed native statuses were 0, so preservation of nonzero native errors remains untested.
- The differential oracle is the native implementation itself; it runs first and warms the kernel, so these case timings are not unbiased performance evidence.
- Entity erase and recreate, address reuse, undo and redo, invalidation during an active computation, cancellation and third-party overrule interaction remain unqualified.
- The qualification command exists only in a test build and its absence from ordinary builds was verified separately.
- The recommendation in the independent review remains no student release.
The external path behaves correctly at the interface boundary for the cases that were tried, including the ones designed to break it: a non-empty prefix and an endpoint-contact geometry both fall back to native rather than producing an answer. The remaining gaps are lifecycle and error coverage, not the cases exercised here.