Caching Regexes in GiGi

[cyanic]

Finally got a patch ready for you all that uses Boost thread local storage to cache the regular expressions used by DetermineLines. You should see a marked speed improvement while switching star systems, going to research, etc.

There are no changes to Font.h.

See also
viewtopic.php?f=9&t=8835

I release these changes under the GPLv2 or later license.

[Geoff the Medio]

Finally got a patch ready...

Could you add a signature or line to the post stating that you release the changes under the GPL 2.0 or later?

[vincele]

Hello,

you've got a typo : "behavoir" in comment

class RegexHelper - wouldn't this be better as a struct ? (I'm not very C++-savvy, so this may be a stupid idea)

I'll test your patch, it may help my poor laptop

[adrian_broher]

class RegexHelper - wouldn't this be better as a struct ? (I'm not very C++-savvy, so this may be a stupid idea)

There is no difference between structs and classes beside the default access level for member attributes or functions.

[vincele]

That, I remembered, but thought there was something else...

[vincele]

FYI, the patch needs: "patch --binary -p7 < Font.cpp.patch" to apply under linux (CRLF & full path)

[vincele]

The patch builds and runs, no bugs found, but the sidepanel display when switching systems does not seem vastly faster with the patch. BTW this is for an LLVM clang-3.6 DEBUG build under linux...

Opening to prodwnd seems faster, as well as a full researchwnd seems more responsive to move around, very unscientific testing report...

[cyanic]

Hello,

you've got a typo : "behavoir" in comment

class RegexHelper - wouldn't this be better as a struct ? (I'm not very C++-savvy, so this may be a stupid idea)

I'll test your patch, it may help my poor laptop

Yes, behavoir is a typo.
I left RegexHelper as a class due to my own style of classes being something you should "new" (as is done by RegexHelperPerThread) and structs being something just declared. I don't care if you all change it to struct, but be aware that the boost xpressive library is very exacting with its types and it can be annoying (hundred line error messages) to keep it happy when things are changed.

[cyanic]

The patch builds and runs, no bugs found, but the sidepanel display when switching systems does not seem vastly faster with the patch. BTW this is for an LLVM clang-3.6 DEBUG build under linux...

Opening to prodwnd seems faster, as well as a full researchwnd seems more responsive to move around, very unscientific testing report...

I believe someone else found a way to not call DetermineLines when moving TextControl around, so that's probably why moving the full researchwnd is more responsive for you.
viewtopic.php?f=9&t=8980

I'm testing on MSVC 2010 Windows 7, profiling using Very Sleepy. I tested by loading FreeOrion, quick starting, clicking back and forth between the home and nearest star system (to deal with any one-time loads) and then clicking back and forth between the home and closest star system 5 times (so 10 total transitions, waiting until everything has finished loading on one transition before doing the next).

So now some real numbers:
Testing against SVN 7634 - 10 star system selections between Escher Alpha and Wedge Beta
without patch:
Trial 1: operator new: 3.38s | free: 3.15s (about 30% of calls come from boost::xpressive)
Trial 2: operator new: 3.81s | free: 2.96s
Trial 3: operator new: 3.26s | free: 2.80s
with patch:
Trial 1: operator new: 3.79s | free: 2.08s
Trial 2: operator new: 4.86s | free: 2.85s
Trial 3: operator new: 3.42s | free: 2.01s

Average without patch
operator new: 3.48s | free: 2.97s
Average with patch
operator new: 4.02s | free: 2.31s

Free and operator new are the two most prominent elements in the profile report (if you disqualify Sleep).
So it looks like, on average, the gains in free are lost in new. That being said, the public release 0.4.3 (SVN 7108) spends almost no time in operator new under a similar test, so maybe something good will come when it is built for public release.

Now, because it took months for me to get this patch to you (had to learn way more about boost than I expected), I think most of my thunder has been stolen by smarter usage of TextControl (so DetermineLines is called less than it was in SVN 7115 when I started).

[vincele]

Now, because it took months for me to get this patch to you (had to learn way more about boost than I expected), I think most of my thunder has been stolen by smarter usage of TextControl (so DetermineLines is called less than it was in SVN 7115 when I started).

Maybe you can do a quick test with you patch applied before and after r7383, that'll tell you if it's that one.

[Dilvish]

For anyone on windows having trouble applying that patch, here is a remade patch that should be usable by TortoiseSVN

[Dilvish]

It appears that this patch breaks the multi-line file dialog rows. Without it my savegame load dialog is fine, but with it I get this:

fileDialog.png (31.83 KiB) Viewed 1813 times

[vincele]

It appears that this patch breaks the multi-line file dialog rows.

Are you sure, I've seen it but remember looking at the same thing in an unpatched FO and also seeing the bug, maybe I mixed some of my binaries...

[Dilvish]

It appears that this patch breaks the multi-line file dialog rows.

Are you sure, I've seen it but remember looking at the same thing in an unpatched FO and also seeing the bug, maybe I mixed some of my binaries...

Totally sure; I just confirmed it-- clean build, no problem, apply the patch and rebuild, get the problem shown above.