polserver / polserver / 35507859038

82%

Build Type

push

github

Committed by web-flow

Commit Message

Read a world faster, and report where the time went (#965)

* Read a world without rebuilding a property tree for every element

ConfigElem kept its properties in a std::multimap. Building one element allocated
a tree node and up to two heap strings per property line and freed them again for
the next, millions of times over, while readProperties() probes ~90 fixed names
against the dozen an element carries - so most probes paid a full tree descent in
order to miss. It is a flat store now: a run of hashes scanned in order, the name
compare only confirming a hit. clear() forgets the live count and removal
tombstones the slot, so the vectors and their string buffers are reused rather
than reallocated. PropKey carries a name with its hash and converts implicitly
from what call sites already pass, so literal names are hashed at compile time and
none of the ~900 call sites changed.

remove_first_prop still answers in name order, which its callers depend on: menu
entries are built in it and read_movecost() interpolates over it. It sorts once
and walks a cursor, so draining a large element stays N log N.

Smaller wins on the same path:

 - the line reader uses memchr over its own buffer instead of a locking fgets plus
   a copy, and reads binary rather than letting the CRT translate CRLF
 - a line is validated as utf8 only once a high bit shows up, which for world data
   is almost never
 - items.txt and storage.txt share one stack of the containers the loader is
   inside, pushed for every container rather than only top-level ones; storage.txt
   had none, so all 2.4 million of its elements paid an object hash descent
 - equiptest.ecl and unequiptest.ecl are located once, not per item per package
 - ObjectHash::Insert makes one tree descent rather than two
 - the zone integrity scans in add_item_to_world and SetCharacterWorldPosition are
   paranoid rather than plain asserts: INC_PASSERT is on in release builds and they
   scan a 64x64 zone linearly, so fill... (continued)

Coverage Stats

389 of 439 new or added lines in 17 files covered. (88.61%)

11 existing lines in 6 files now uncovered.

60029 of 73425 relevant lines covered (81.76%)

1606001.74 hits per line