Do not begin optimization by applying somebody else’s triangle budget. Begin with a repeatable test. Without one, a quieter server or a different camera angle can look like a successful optimization.
This is an engineering workflow for the map you built, not a set of benchmark claims about CodeWalker or FiveM.
Freeze the baseline
Record the candidate asset version, client machine, graphics settings, resolution, target edition and server resource set. Choose fixed observation points: the street approach, entrance, main room and the most detailed interior view.
Run the same route several times. Record frame time when your measurement tool exposes it, along with the conditions of each run. Include both a cold approach and a repeated visit; do not compare one against the other without labeling the difference.
A change is useful only when the test measures the same thing before and after. Save the original package so you can retest it directly.
Separate the dimensions of cost
Inspect visible geometry, material variety, texture dimensions, collision complexity and the amount of content exposed through openings. These are distinct design dimensions. Reducing one does not prove that another stopped being a bottleneck.
Make a small intervention, such as simplifying one decorative object, then rerun the route. If the difference is within the noise of your baseline, record that result rather than inventing a performance gain.
For a dense scene, a plain diagnostic version can be useful. Remove one class of optional decoration in a separate test build, leaving room structure and placement intact. This is an experiment, not the final optimization.
Use level of detail intentionally
The CodeWalker README explains GTA’s hierarchical level-of-detail organization and the relationship between detail selection and camera distance. It also notes that some high-detail content depends on the appropriate map context being loaded in the viewer.
A low-detail model should preserve the silhouette and the large visual features needed at its viewing distance. Inspect the handoff from several approaches. A smaller mesh is not a good result if it produces a distracting pop at the entrance.
Do not fix every visibility issue by increasing draw distance. First check placement, bounds and the relevant hierarchy. A wider distance can conceal a structural mistake while exposing more content than intended.
Audit textures with the asset in view
List texture dimensions, repeated content and actual use. A large texture on an object that occupies very little screen space deserves a closer look. So does an accidentally duplicated texture dictionary.
Use a controlled replacement test: change the resolution of one asset, inspect it at the closest legitimate viewing distance, and compare the measured route. Keep enough quality for the intended use rather than optimizing a number in isolation.
Do not equate on-disk ZIP size with runtime memory cost. Compression, texture formats and asset loading behavior affect different parts of the system. Report what you measured rather than substituting one metric for another.
Recheck the interior graph
A visibility fix that exposes the entire interior from every nearby viewpoint can have a different cost from a properly scoped room setup. Inspect the room and portal tests again after structural changes.
Do not remove useful room boundaries merely to hide a portal bug. Keep correctness and optimization as separate acceptance criteria: the map must first show the intended content, then do so within the performance conditions you are targeting.
Publish observations, not universal claims
A useful performance note states the hardware, settings, test route, comparison versions and observed result. “Optimized” without those details does not tell another server operator much.
Finish with the release checklist. Reconnection, collision and neighboring-resource tests still matter after a successful timing comparison. An optimization that breaks a doorway is not a shippable improvement.