Hi all. Thanks very much for this thread, it has uncovered a quite inefficient code path in chunk resolution that we will be able to sort out.
Indeed, I believe that http://quality.runrev.com/show_bug.cgi?id=14504 was already potentially causing a problem for the 'char' chunk. In theory the engine should detect the use of a native string and process it as such, thereby circumventing any of the the unicode specific code paths. In 7.0 it is worth testing with the codeunit chunk instead if you know you have a native string - if the codeunit version is faster then something related to bug 14504 is probably causing the problem. Ali On 9 February 2015 at 16:06, Bob Sneidar <bobsnei...@iotecdigital.com> wrote: > Then there is the method of storing the data in a memory based sqLite > instance and using SELECT with the ORDER BY DESC ordering term. Might not > be faster, but it should be a lot more flexible. > > Bob S > > > On Feb 8, 2015, at 14:37 , Alex Tweedly <a...@tweedly.net<mailto: > a...@tweedly.net>> wrote: > > Indeed. Jerry was (as usual) correct - if the engine can do it, then the > engine will normally be faster. > > BUT sorting a list requires moving the data around quite a lot, AND > sorting something that actually reverses it can be a pathologically bad > case (e.g. if the engine uses any variant of quicksort()).. > > > _______________________________________________ > 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 > _______________________________________________ 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
