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