On Mon, May 11, 2015 at 11:01 AM, Richard Gaskin <ambassa...@fourthworld.com > wrote:
> 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. Having just used LC 7 to make SQliteAdmin handle Unicode, I didn't experience any real degradation in performance. If I had taken the time to measure the milliseconds required for various operations in the pre-Unicode version (built with LC 6.6.2) and the Unicode version (built with LC 7.0.4), I may have seen some increases but from a user perspective, none were evident. The application does not handle huge amounts of data. In general, I'm parsing SQL statements and displaying data from tables in a datagrid. I use the dgNumber of records feature of the datagrid to populate it so no matter how many rows are displayed from a table, only a small number of them are parsed for display at any one time. There was definitely an increase in the size of the standalone (about 50%) and building a standalone took a lot longer but still only a couple of minutes. All in all, I was very happy with how easy it was to add Unicode capabilities to this application, especially given that it's whole purpose is to handle communication with external databases. I had tried to do it a few weeks ago with LC 6.6.2 and pretty much gave up due to the complexities of handling Unicode within LC. So for my application, LC7's Unicode features were definitely worthwhile since I had received requests from my users to enhance it to handle Unicode. Pete lcSQL Software <http://www.lcsql.com> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html> _______________________________________________ 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
