On Wed, Oct 5, 2011 at 22:36, Thonsew Thonsew <[email protected]> wrote:
> The t_token solution makes lookup and comparison of values in a cfg O(1) in
> the length of value_name, and the number of values. It solves the problem as
> can be seen in attached perf report 2, perf_results_R51388.png, which shows
> the 25% improvement when you compare the 104K samples to the 74K samples for
> the same task. You can also note that most of the gains are in constructing
> fewer objects. The remaining gains are in comparison operations.
Have you tried profiling other usecases? A slowdown in startup of the
test scenario has been reported. [1]
> D. Why two classes shared_object for tstring and t_interned for t_token?
> shared_object was created to reduce the storage requirements of tstring and
> t_interned was created to improve speed. Currently they are almost
> identical, but in future they maybe optimized in different directions to
> serve these 2 different masters, size and speed.
This sounds like a premature preparation for optimization to me. If
it's currently mostly-identical to shared_object, you should just use
that and fork it if needed later on. Another option is
boost::flyweight, which requires boost 1.38.
> 2. Replacement for a string literal
> String literals are static objects so a string literal of the form
> "string_literal" should be replaced with
>
> static const config::t_token & z_string_literal(
> generate_safe_static_const_t_interned(n_token::t_token("string_literal")) );
>
> 3. Replacement as a default value in a function definition
> String literals as default values are static values with the tricky
> dynamic that the creating function will be called repeatedly, so
> void funcD(std::string dd = "def_val");
> needs to be replaced with a macro to create the function and then the
> function are the default value.
>
> DEFAULT_TOKEN_BODY(z_def_val_default, "def_val")
>
> void funcD(t_token dd = z_def_val_default());
The syntax required in these two usecases is completely unacceptable.
I do not want to litter my code with stuff like that.
My opinion on how we should proceed:
-Revert the t_token commits from r51053 on. I am willing to do the
work somewhere this weekend.
-Profile current SVN head against r51052 or 1.9.9 (this doesn't
include the unordered_map changes, which preceded t_token). Not only
the AI turn, but test scenario startup, WML cache creation, reading,
campaign loading and such.
-If t_token is still a clear improvement, (re)design and (re)write
t_token (possibly with a more meaningful name. We used to have
shared_string) with a clean interface similar to std::string. All
known issues (lua, static initialization) should be fixed before it is
deployed.
Alexander <AI>
[1] https://gna.org/bugs/?18771
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjk9NAAoJEO0or+AHBBofMKgP/2KQHaguvd2rpOOactAEYxCr
5IHPjjc76waPa6oRKiQk4KurXvtbLmON6ZpP3SvlYUfhw/F33eEia/0z5b3ReKRr
oMS4XJFNfJC/PnxwuNErgVRU2+LktyelhAUsoPxMBxDU6okcOZg+U0EH/26YluVl
kDfoGogEF6JIv5bMdyFxvmTq8JYWifZvLY2R7TElXu2dSfhpEmFeUN/dk9EfoGel
C2JjBNHOW1fs6jPQ+3nONux+Q8I8zmIjhKaXQvYN9rWHzx4EURbIkZHz2oZgCqr1
ZAs+vEqmnd9rVzg52VjEDzgDGj3C2r2OcZJSQz0EcwfVEo14IQWA0N2yfaBKEpsZ
qFe2ixH2m9sgKKQLqDlbqRHSq8WP9diSW4/eLr6CrpY37l2qU9YAMt4LiB7JF2qc
xJgvjKZb6RJIj+FkVAofWbiNIMwKGGKUa6M4MKX0I2HfhPHSic9i8HsGA6CnWbNS
lCLUWMRInkQioXjQC10OfUjwTCdBl7TSjlmo3opjPcdj4mkYrjV0SxU4Obzyra9M
aO7diCXFUTkGX1kSuwiM4EIpVhfnGv6TvGtCzSIIqjw9qOvEpB0l/ojUe9kAPs1g
newL9Udc4baObWPeRdc6LHPqazZZ8YeLYtVrWIbAChDtaqs8/oCGII57JW+RtFdT
osi9S72dBWhYgY3CiJUM
=71HS
-----END PGP SIGNATURE-----
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
