Thanks for your thorough answer!
We appreciate it!
>> As far as we can see, in the one-time use, unnecessary declaration lines
>> are executed and slows down the execution.
>>
>> We have done some testing and can see that execution of:
>>
>> var xx = "test string";
>>
>> widget.setToolTipText(this.tr(xx));
>>
>> takes longer time than
>>
>> widget.setToolTipText(this.tr("test string"));
>This really depends on the browser/OS your testing on. E.g. AFAIK this is
>not true in IE, at least not in the older versions, where this
>optimization is crucial. If you target non-IE browsers with your app, you
>may want to disable the "strings" optimization in your config.
ok. interesting!
>Also, your notion of "one-time use" is ambiguous. Do you mean *lexical*
>use?!
With one-time use I meant lexical reference.
> A string might be appear only once in the code, but the reference is
>in a loop,
True!
Easy to see, though the loop iterations can be from 0 and up. Can only be
optimized by >1 iterations with the string declaration inside the loop.
Most loops do iterate >1 so where the loop comparator is a constant it is known
but else not possible to foresee.
It means that there is only one case left, which might be a small case, to
optimize, where the comparator is a constant example:
for (var x = 0; x < 7; x++)
> or within a function that is called often.
True. Impossible to foresee. Can be anything and as the local var declarations
are "in" the namespace of the class they are not redeclared.
As a loop is within a function means that trying to optimize further than you
have already done is useless here.
But one more question is about the browsers built-in optimizations. Does that
change this rule of optimization i.e. does any browser do this optimization
with local variables for strings "within" the namespace of the class?
If it does, then the string optimizations could be optimized. But if not all do
then it is useless again.
We still have one problem here. The strings related to functions which never
will be called steal execution time and memory on the heap when it is declared
in the beginning of the class. The question is if it is possible to sectionize
it even further i.e. more related to the specific function where is it used?
Now it is related to the whole class i.e. local to the whole class.
What do you think about that?
What is your opinion and findings here?
> So a single
>appearance in code can mean a lot of uses at run time. This is hardly
>foreseeable by the optimizer.
True, if not ALL browsers optimize themselves. Apparently, they don't seem to.
>> 2. We have also noticed that you put the names of the local variables
>> holding the strings mentioned above to the same, i.e. they are not for the
>> application globally named. Is there a specific reason for that, more than
>> you might want to keep modularisation, which we believe is not relevant
>> here as the code can not be pruned and grafted with other pieces of code
>> after generating it.
>For one thing, I wouldn't expect much space saving if the string vars were
>global. But on the other hand I'm very happy for every optimization that
>can be applied to a class independently of all the others, as independent
>handling of class code becomes more and more important.
Only the translational .po key values, mentioned below, as far as we can see
and also the implementation of a more local function related string declaration.
>> 3. We have previously added an enhancement bug text about the translation
>> strings and converting the .po files in the .js files. Now the key of the
>> translation string is multiplied in all language .js files and in the
>> execution code file too. This could be collapsed if global keys were used
>> instead of the long original key strings. The global key should be
>> "dynamic" in size 1, 2 or 3-byte long.
>This one is interesting, but I'm not aware of any targeting for this bug.
We are very interested in this as we have huge amount of text in the whole
application and the leaner the translation text data can be the better.
Stefan
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
