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 ____________________________________________________________________ ambassa...@fourthworld.com http://www.FourthWorld.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
