You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While debugging why our custom scenario graphics aren't working (again), I noticed via breakpints that Util.Civ3MediaPath does an awful lot of checking whether files exist, particularly files such as rolloverbuttons.pcx that are requested repeatedly. It checks with the file system whether they exist, and if not, checks additional locations until it finds them.
Optimizations should benchmark this to see if improvements are discernable. Testing with a nice slow hard drive is likely necessarily. With my 7200 RPM Toshiba desktop hard drive from 2013, loading a scenario is still pretty quick, so if I had it on a modern SSD I don't think we'd be able to tell much of a difference at all. That's part of why this is low-priority, but nonetheless it jumps out as "something inefficient we're doing unnecessarily".
I expect to eventually have a whole bunch of these "potential performance improvements" documented as they are discovered, so once we decide something is slow it's easy to look up possible ways to speed it up.
The text was updated successfully, but these errors were encountered:
While debugging why our custom scenario graphics aren't working (again), I noticed via breakpints that Util.Civ3MediaPath does an awful lot of checking whether files exist, particularly files such as rolloverbuttons.pcx that are requested repeatedly. It checks with the file system whether they exist, and if not, checks additional locations until it finds them.
Optimizations should benchmark this to see if improvements are discernable. Testing with a nice slow hard drive is likely necessarily. With my 7200 RPM Toshiba desktop hard drive from 2013, loading a scenario is still pretty quick, so if I had it on a modern SSD I don't think we'd be able to tell much of a difference at all. That's part of why this is low-priority, but nonetheless it jumps out as "something inefficient we're doing unnecessarily".
I expect to eventually have a whole bunch of these "potential performance improvements" documented as they are discovered, so once we decide something is slow it's easy to look up possible ways to speed it up.
The text was updated successfully, but these errors were encountered: