how possible would it be to makes something similar to thonsew's
change in a more safe/readable way ?
I am thinking in particular of the _("mlkjml") syntax of gettext...
could a similar marcro jiu-jutsu be used for WML reading ? or is there
some specific changes in the compiler to be able to implement it ? i'm
not very good at that, just wondering...
2011/10/7 Alexander van Gessel <[email protected]>:
> 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
>
> _______________________________________________
> Wesnoth-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/wesnoth-dev
>
>
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
