[Ohrrpgce] [ohrrpgce/ohrrpgce] Some browsers are unusably slow in large games or slow computers (#1)

[Ralph Versteegen]

I'll call this fixed. Through a bunch of optimisations (there were a lot more causes of slowness than I expected), I managed speed-ups of up to x35, (and that's not even including my rewrite of the palette cache, which gives another ~30% boost to spriteset browsing, but I'll leave that until after Fufluns).

A summary of the improvements: times to enter a menu for the first time (in milliseconds on an AMD FX-6100 3.3GHz which is a 2011-era CPU):

```
Vikings
|           | Enemies    | Attacks    |
|           |  Old | New |  Old | New |
| WindowsXP | 2230 |  63 | 1194 |  92 |
| Linux     |  314 |  24 |  114 |  29 |

The Adventures of Powerstick Man
|           | Textboxes  | Walkabouts  |
|           |  Old | New |   Old | New |
| WindowsXP | 3343 | 815 | 17217 | 591 |
| Linux     |  678 | 326 |  3595 | 163 |
```
0.8 seconds to enter the textboxes menu is still a bit unpleasant, though.

`lazyclose` is mostly to thank for narrowing the gap between Windows and Linux. Here's detailed breakdown of timings (milliseconds) for entering the Textbox thingbrowser in Vikings, showing `close` vs `lazyclose`

```
|              |           | OPENFILE | Close | loadrecord |    Fill | Create | Total |
|              |           |          |  file |            | TextBox | planks |       |
|              |           |          |       |            |         |        |       |
|--------------+-----------+----------+-------+------------+---------+--------+-------|
|              | CLOSE     |      352 |   228 |        248 |      50 |     94 |  1058 |
| WindowsXP    | LAZYCLOSE |       47 |    40 |        140 |      48 |    106 |   429 |
|--------------+-----------+----------+-------+------------+---------+--------+-------|
| WindowsXP    | CLOSE     |      283 |   186 |        244 |      54 |     90 |   928 |
| nomutex      | LAZYCLOSE |       17 |    18 |        135 |      46 |    104 |   359 |
|--------------+-----------+----------+-------+------------+---------+--------+-------|
|              | CLOSE     |      257 |    80 |        130 |      46 |     85 |   628 |
| Windows10    | LAZYCLOSE |       20 |    16 |        107 |      45 |     81 |   299 |
|--------------+-----------+----------+-------+------------+---------+--------+-------|
|              | CLOSE     |       30 |     6 |         28 |      27 |     54 |   148 |
| Linux        | LAZYCLOSE |        5 |   0.4 |         29 |      27 |     54 |   116 |
```

Key:
* Close file: CLOSE or lazyclose
* loadrecord: excluding open and close time - just seeking/reading (NOTE: these timings were taken before I optimised loadrecord
* Fill Textbox: LoadTextbox except time spent in loadrecord (including the open and close)
* Create planks: build_thing_list except time spent in LoadTextBox
* Windows10 is 19.10.
* "WindowsXP nomutex" is with mutexes in filelayer.cpp commented out (they are completely unnecessary at the moment, since we don't do file I/O on multiple threads).

Note: The timing adds a lot of overhead, and I didn't try to fix the CPU frequency. That's why you see switching from `close` to `lazyclose` affecting things it shouldn't.

Note: Comparisons across OSes aren't fair: all are on AMD FX-6100 CPUs, but Win10 is running on a CPU clocked a little slower, Windows XP is running under Virtualbox (which slows down syscalls particularly), Linux times are while running under gdb. Also I used GCC 9.1 on Linux and GCC 4.5 on Windows, which I think is to blame for the 'Fill TextBox'/'Create planks' OS differences.

Not to mention the improvements to the map browser, which was another part of this bug.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1#issuecomment-570059617
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200101/172fd026/attachment.html>