Speedtest "set the unicodeText of fld"

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
snm
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 253
Joined: Fri Dec 09, 2011 11:17 am
Location: Warszawa / Poland

Speedtest "set the unicodeText of fld"

Post by snm » Thu Oct 31, 2013 5:18 pm

I have field "Field" and button with script:

Code: Select all

global tTest
on mouseUp
   put the unicodeText of fld "Field" into tTest
end mouseUp
In the first phase of test I type word "babel" into this field and run the script:

Code: Select all

global gTest
on mouseUp
   lock screen
   put the milliseconds into tTime
   repeat 10000 times
      set the unicodeText of fld "Field" to  gTest
   put the milliseconds - tTime into msg
   unlock screen
end mouseUp
It takes 140 ms
Then, in the second phase of test I'm typing into the same field the word "bąbel" -> only changed the second char from "a" to accented "ą".
Then after run the script again it takes 459 ms.

Why it's over 3 times more? The same script, different only 1 character in the variable.

Marek

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Speedtest "set the unicodeText of fld"

Post by LCMark » Thu Oct 31, 2013 8:07 pm

@snm: Laying out unicode text takes a lot longer than non-unicode text as the engine uses proper text processing APIs to do it. The non-unicode text code paths are a great deal faster, albeit at the expense of typographic quality (you don't get ligatures and such). So this is why you are seeing the difference in speed.

However, in 6.5 we've moved to using proper text processing APIs for all text, and due to this have spent a good deal of time optimizing the field layout and redraw. Indeed, using a similar script to you I get the following:

6.1.x: non-unicode = 100ms, unicode = 300ms
6.5 (frontier): non-unicode = 100ms, unicode = 140ms

So, yes it is quite a bit slower currently, but we've closed the gap considerably for the next major release.

snm
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 253
Joined: Fri Dec 09, 2011 11:17 am
Location: Warszawa / Poland

Re: Speedtest "set the unicodeText of fld"

Post by snm » Thu Oct 31, 2013 10:27 pm

Thanks for explanation Mark, but I still don't understand how ligatures and such could slow down the speed of off-screen operations on just few bytes without redrawing the content of field.

Marek

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Speedtest "set the unicodeText of fld"

Post by LCMark » Fri Nov 01, 2013 11:12 am

Well, whilst nothing is being drawn under lock screen, the field does recompute its layout after each change so work is being done. (We are looking into making the field defer its layout operations until needed, which would make the code in question substantially faster).

Recomputing the layout involves iterating over each paragraph, and then over each style-run in the paragraph; and an important thing to bear in mind is that the field stores text as mixed runs of unicode and non-unicode text - thus 'babel' will be a single style run, and 'bąbel' will be three ('b', 'ą', 'bel'). (This is something we've changed in the unicode/refactored branch of the engine we've been working on - paragraphs will either be unicode or not, thus eliminating this source of extra work).

In the current engine (<6.5), on each layout the engine will be measuring the length of each style-run using a very fast (but not typographically accurate) mechanism for non-unicode text, and a slow (but typographically accurate) mechanism for unicode text. This means that in the timings for these engine versions most of the work is being spent in the slow text APIs for the unicode text.

In 6.5 we've mitigated the time it takes to measure strings substantially as text is broken up at appropriate points and these smaller strings measured once and the information cached. This means that the time taken (when repeating the same operation) is essentially measuring the time taken to iterate over the fields data structure to recompute its layout (as after the first time the strings have been measured, they won't be measured again through the slow APIs).

Thus, in the unicode code case, the engine is doing three times as much work as in the non-unicode case. So the timings look like they are demonstrating a constant overhead of around 80ms for doing everything not including iterating over the style runs 10000 times, and 20ms for processing a single style run 10000 times.

So to sum up, the reason the unicode text is slower in the pre-6.5 engine is a combination of the data structure being 3 times the size (3 runs not 1) and the APIs used to measure the unicode bit being substantially slower than that of the non-unicode bit; and the reason it is still slower in the 6.5 engine is just the difference in processing 3 runs not 1 10000 times (since the cost of measurement has - over 10000 runs - been essentially eliminated).

[ Incidentally, the reason the text processing APIs are slower is because they are doing a great deal of work - the characters of the string need to be mapped to fonts that can deal with them, then the characters need to be mapped to glyphs, then the font might have various tables that operate on those glyphs doing things like forming ligatures and performing kerning, and finally the glyphs need to be positioned so that the width of the string can be computed ].

snm
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 253
Joined: Fri Dec 09, 2011 11:17 am
Location: Warszawa / Poland

Re: Speedtest "set the unicodeText of fld"

Post by snm » Fri Nov 01, 2013 2:47 pm

Once more thanks a lot for detailed explanation.

Marek

Locked

Return to “Engine Contributors”