Kickstarter 2013 Revisited

Richard Gaskin ambassador at fourthworld.com
Mon May 11 14:01:35 EDT 2015


Geoff Canyon wrote:

 >...I was just saying that since the language *itself* is in english,
 > how much of a difference does it make to work entirely within the
 > ascii character set? Obviously some (a lot?) but if that were the
 > only use-case for unicode it would be thin indeed.

Unicode is the modern standard to text handling, and it's been this way 
for so long that LiveCode couldn't be taken seriously by a great many 
people without it.

Of the Top 100 languages on the TIOBE list, are there even as many as 
three that don't support Unicode?  Even just one?

Whether or not we localize, Unicode is how text happens in the 21st 
century, found in everything from clipboard contents we need to handle 
to the paths of files we need to read from.

So while the value of Unicode is, at least for the purveyor of a 
development tool, beyond question, the unknown is its impact on LiveCode.

We know it impacted the development very significantly, but beyond the 
other two areas of concern are the size of standalones and their 
performance, and in these the impact of Unicode has not been clear.

A couple members of the core dev team have suggested that the Unicode 
libraries do play a role in much of the additional file size of 
standalones, but contrary to popular perception have also clarified that 
the interconnectedness of Unicode within LC is not so great that it 
can't be factored out into a build option for those needing the smallest 
standalones possible.

As for performance, we can anticipate that some string operations will 
take longer by virtue of memCopy moving twice as much data.  But the 
speed differences between 6.7.x and 7.0.x have been quite varied, and 
not intuitively apparent as related to Unicode.

As is common in many languages, we used to run isolated performance 
benchmarks to identify specific differences and their magnitude, but in 
recent months such tests have been called "synthetic" and dismissed as 
irrelevant given the many algorithmic changes under the hood.

One the one hand I can certainly appreciate how algorithmic changes can 
make certain benchmarks less meaningful in terms of where a developer 
might look to optimize them.

But from the standpoint of the scripter, and by extension their 
end-users, it's still very helpful indeed to be able to identify that a 
given app relies heavily on the lineOffset function, for example, so 
finding a 3-fold slowdown there would seem useful for very practical 
purposes.

Not having spent time in the underlying C++ I'm at a loss to explain why 
it's too hard to bring things like lineOffset closer to their 6.x 
performance, and the current suggestion of tossing out our benchmarking 
scripts in favor of sending an entire, sometimes complex, app to be 
diagnosed to eventually identify that same bottleneck seems a mysterious 
path to me.

Clearly I could benefit from some education from the core dev team on 
benchmarks, performance differences, and efforts being made to restore 
performance closer to previous levels.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list