These practices come from the HP Exstream 8.x era, and the specific thresholds are historical. The underlying practices still apply because they follow the composition path: input mapping, object evaluation, rendering, and output handling.
Measure the whole path before touching the design
Performance problems should be measured along the full path before anything is changed. Separate engine time from upstream data preparation, downstream delivery, and file handling. A slow "Exstream job" regularly turns out to be a slow data extract or a slow output copy, and design changes cannot fix either.
Run high-volume tests during development, not only at the end. A design decision that is cheap at preview scale can be expensive across a production population, and the difference only shows up under volume.
The data layout is part of the performance model
Remove unused variables from data files and unmap fields the application never reads. Avoid data sections without a defined composition purpose. Every mapped field is work the engine does per customer, whether or not anything uses it.
For unfamiliar territory (new output drivers, sorting, barcodes, file breaks), build a prototype with representative input and output requirements before committing to the full design. For teams on a shared design database, use supported multi-user check-in and check-out, and do not place the design database across a WAN; the historical guidance was blunt about this and remote-collaboration pain confirms it.
Object count is a real cost driver
Reduce unnecessary page design objects.
Join table cells where the layout allows, and use tab sets and margins for alignment instead of positioning every character; the Position Every Character option imposes substantial output cost and belongs only where the target channel genuinely needs that precision.
Keep static content static so packaging can pre-draw it. Use components and library objects for repeated content instead of maintaining copied variants: an object used in several places should become a library component, while a copied object is a deliberate branch and should be documented as one. Dynamic Content Import can improve package times when many images are external, but image resolution and dimensions still need to match the output use.
Logic structure ages better than clever logic
Delete formula variables that add no reusable computation. Use nested conditions so branches are not evaluated when their prerequisites are false, and do not re-execute a loop over a count that can be computed once. Avoid embedding calculations inside layout objects, where their dependencies are invisible.
The naming rules matter more over a decade than any single optimization: name variables by purpose and data relationship, distinguish formula variables from data variables, and write descriptions so a later maintainer can identify intended timing and scope. Pick include or exclude and use it consistently; double negatives in rule logic are a standing invitation to production defects. Keep hard-coded values that may change between environments in initialization or reference files.
Exit criteria: a clean message file
An upgrade-ready application leaves unit testing with a clean engine message file. Packaging warnings, missing-resource messages, and unexpected rule evaluations are either fixed or consciously accepted and recorded, never ignored. A clean message file keeps known warnings from hiding new upgrade failures.
A note on currency
Thresholds and tradeoffs depend on the output driver, data volumes, fonts, images, and platform, and the Live-era validation advice from this period applies only to installations still running that stack. Treat the specifics as a starting point for measurement in your own environment, not as guarantees.