Thanks for the post. You should get a T-Shirt printed for your tour in black with white writing
It depends. ;-) And, of course, it really does depend. Operations at scale are different than operations on small collections. They're different problems. Yet another reason it's helpful to have a testing framework so that you can find how operation perform in different environments. Something that works great for 1000 items might be terrible for 100,000 - and something that's a huge help at 100,000 might add pointless overhead at 1000. There are some very, very large scale 4D databases out there but, mostly, they're not so big. (At least, that's my experience.) So, if I have to guess, I guess people are talking about general-case, small-medium situations, unless they say otherwise. > What do you mean by "Best way"? The easiest one? The fastest one to program? The most efficient > one? The most efficient is probably to mimic the way LR has programmed the Object Indexes. But this is > NOT the easiest one, I can guarantee you... Yes, it would be understand how LR programmed object indexes as it provides a good way to develop theories about good strategies and to then *test* them. The only way to know what is better in some situation is to test it out. (Obviously, algorithms can be compared abstractly but we're usually talking implantation on this list.) How the hash tables are implemented for memory-only objects is also important to know about. Can you say how the hash tables and object indexes are implemented in 4D? It ought to be explained in some form of documentation, but doesn't seem to be. Sadly, many of 4D's features are not adequately documented. I haven't found much of anything on subforms widgets or the dual-process business on 4D Server. So far, I've found 4D's objects to be remarkably fast to access - far faster than I expected and it would help to know more about the underlying data structure(s) and algorithm(s). As an example of when and why it's helpful to understand underlying data structures and implementations, I can say it in a word: XML. 4D didn't have a meaningful tree structure before XML and a lot of 4D programmers haven't had to deal with trees directly. When I see slow DOM XML code, it's typically not hard to cut the processing time in half. How? By replacing 4D's DOM find commands with a comprehensive tree walk that visits each node once and only once. You traverse the entire tree, but with no waste. Using the wrapper commands in the language, you're presumably asking 4D to walk the whole tree over and over until you find what you want. You can construct unlikely examples where the difference makes a *massive* speed difference. But, in general practice, I figure a 2 to 1 improvement. Just a rule of thumb, the real difference absolutely depends. This is also one reason that I use XML Tools as it provides a super easy way to get good performance without hassling with a tree walk. Anyway, I don't know how the XML library 4D embeds works internally, but understanding that it's a tree and has to do a tree walk, it's not hard to see where the inefficiency comes from. Unless there's some kind of magic index (and I wouldn't expect or even want one), doing 'find in DOM' means lots of redundant traversals. I'm hoping to hear a thumbnail explanation of that sort for 4D's hash table/object implementations. That would be great! And while it's really, really great that 4D has being doing these road shows while also continuing to put on Summits, it's not possible for people to attend. It's better if you can attend but, if not, the information ought still be available in a reliable form, I'd say. It's better for 4D as more people understand how to succeed with the product. ********************************************************************** 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:[email protected] **********************************************************************
