Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-07 01:46:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add seven performance knowledge articles from BC developer guidance

Browse source 
Cover non-obvious platform behaviors a capable LLM reliably gets wrong:
hidden FlowFields still calculate, LockTable scopes to the whole table,
query objects bypass the primary-key cache, table-event subscribers
disable bulk ModifyAll/DeleteAll, Blob fields are uncached, OnCompanyOpen
subscribers block every session creation, and the test framework
disables bulk insert mode.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jesper Schulz-Wedde 2026-04-24 10:38:28 +02:00
parent dc14e7bb2a
commit 800e266bfe
7 changed files with 176 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

26
microsoft/knowledge/performance/uninstall-test-framework-to-measure-insert-performance.md Normal file
View file

@ -0,0 +1,26 @@
---
bc-version: [all]
domain: performance
keywords: [test-framework, bulk-insert, performance-test, benchmark, insert]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Uninstall the test framework to measure insert performance
## Description
Business Central's server uses a bulk insert optimization that batches multiple row inserts into a single SQL round-trip when conditions allow. When the test framework is installed on the environment, that optimization is disabled — inserts fall back to one SQL statement per row. The behavior is a side-effect of how the test framework instruments AL execution and applies whether or not any test is actually running.
For functional tests this is invisible; for performance measurement it is catastrophic. A benchmark that inserts ten thousand rows with the test framework present reports a number that has nothing to do with production, because production will not run in row-by-row mode. Treating the measurement as a real baseline produces conclusions that are wrong by a large constant factor.
The same caveat applies to Update and Delete paths where bulk optimizations exist — the test framework's presence suppresses them.
## Best Practice
Before running any insert, update, or delete throughput benchmark — whether via the Performance Toolkit, a hand-rolled harness, or `SessionInformation` assertions — uninstall the test framework from the target environment. Re-install it only for functional test runs. Document this step in the benchmark procedure so future measurements are comparable.
## Anti Pattern
A performance regression report comparing two builds on a sandbox that has the test framework installed. Both numbers are row-by-row timings; the ratio between them may be meaningful, but neither number reflects production, and any absolute throughput claim derived from the run is wrong.