qoncept wrote:
We're using DOM. Once the file is parsed, though, the object isn't referenced anymore. It won't affect speed as only necessary elements are parsed.
I've actually been playing with the ecu defs file lately.
Maybe it's not an issue in Java, but parsing a 4MB XML file isn't very speedy in Ruby. Between four and six seconds on a 1.6ghz box. It's a one-time hit, but it's kind of annoying.
Preliminary testing indicates that it'd be quicker if the defs were broken up. My suggestion for that:
A directory named ecu_defs. This directory would contain:
base_maps, a directory containing one file per 'real' base map (16BITBASE, 32BITBASE)
id_addresses, a file containing each distinct internalidstring address
base_map_list, a file containing each base map name
Subdirectories named for each entry in id_address which contain
one file per ecu def
The logic would be... When an ecu image is loaded, collect the data at each offset defined in id_addresses. For each resulting string, check the corresponding offset directory for a matching file name.
'Chained' base defs are easy enough to handle. Once you have a def picked out, follow the trail of base maps until you get to an entry that matches the name of a file in base_maps.
We could actually skip the id_addresses and base_map_list files by just getting a list of the files in base_maps and the ecu_defs directory.
This way we don't have to process eleventy billion xml elements just to find the one we want.
