Take for example retrieving a large data set from an SQL db. You can retrieve it as a cursor, and array or a string. Cursors are read only and I don't see the advantage of working with them. That leaves only arrays and strings. So if you *can* get the data as an array, and sorting is not an issue, I'd say use an array. If the data you are working with can only be gotten as a string, such as a web query, then you gain nothing parsing it into an array first.
Bob On Feb 21, 2012, at 8:48 AM, Richard Gaskin wrote: > Pete wrote: >> Interesting, and it kinda makes sense. For elements, there's no >> positioning required like with lines/words/item, just a case of cycling >> through the keys - which is what "repeat for each line <x> in the keys of >> <array> does I suppose. > > As with most things in computing, the truly optimal solution comes with a lot > of "depends"; total date size, size of elements, distance from the start of a > chunk to the value being obtained in it, how deeply nested are the array keys > - all those and more play a role in total performance, which can sometimes > yield unexpected results. > > One challenge with arrays is their use in CGIs, where total throughput > performance is unusually critical since the app is born, lives, and dies all > in the space of satisfying a single request from the user. > > The problem with arrays in that context is that they don't exist with the > routine begins, since the engine itself needs to be loaded. > > Arrays offer blinding speed for random access, but they're able to do this > because they rely on memory-specific structures, leaving us with the > question: how do we load the array from a cold start? _______________________________________________ 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
