> ​What I'm seeing is these are techniques most applicable to really large > data objects. I'm most frequently dealing with object arrays of less than > 50 elements. For things this small I can rely on the straight forward 4D > approach. But as I write that I can also see the benefits of a little more > structure in constructing my objects - even if they aren't on a scale where > using Find in array vs. Find in sorted array will make a measurable > difference.
In everyday use, I'd expect that the most common payoff isn't from using a sorted/unsorted array as either will be fast. The big payoff is when you can use a small data type array (longint for example) stored either inside or outside of the larger object to avoid iterating over lots of big objects. If the index array is outside of the object (at least as long as you are inside 4D), you could have 1,000 elements in a tiny array, check it quickly *before* you have to load the object, reconstitute the component objects to get the one you need. That could be helpful in a pretty broad range of situations that ordinary people run into. Problems at scale - like 500K items exist, but they're a lot less common. Still, good to know the range of options. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
