Kirk: You are right how we stick to our old habits. We do though because they have proven to work and sticking with them saves a lot of time.
What we have done is to rewrite our shell every so often. The goal is to make use of all of the new features of 4D that we can, and to try new ways of doing things. We did this over the last year with v16. We really pushed out a lot of the way we used to code and did it the new way we decided on. One thing we did find is that in uncompiled with Team Developer it was slow. We got concerned. I did notice it was also slower on Stand Alone developer but not as bad. We do not use global variables on forms (or in our code), use our own dot.notation in C_Objects extensively, and use pointers even more than before (and with local variables). We finally decided we had better compile it to see what the end user speed was going to be like. We breathed a big sigh of relief as the code executed quickly. I suspect that a lot of the new way of coding gets ‘hard coded’ by the compiler so that it does not have to take the time to create the item in memory - thus the speed increase. Back to the topic of the thread - rewriting our shell though expensive for us, it helps move our mind set, test out new theories, and keep our code up to date with the 4D Technology. Testing is critical though. We got bit very badly with SQL when it first arrived. Once France got involved they identified the cause quickly, and fixed it. Learned a good lesson there - yet again. Jody Jody Bevan ARGUS Productions Inc. Developer Argus Productions Inc. <https://www.facebook.com/ArgusProductions/> > On Nov 28, 2017, at 9:17 AM, Kirk Brooks via 4D_Tech <[email protected]> > wrote: > > Arnaud, > > On Tue, Nov 28, 2017 at 1:26 AM, Arnaud de Montard via 4D_Tech < > [email protected]> wrote: > >> In the same kind of old belief, the "price to pay" to call a method in >> compiled mode is very low, but still passing a pointer parameter seems >> slower than other types of parameters. >> > Good point - another vestigial programming habit that contributes to > long, tortuous methods that are complex, hard to debug and fragile. > > It is interesting how those of us who've used 4D for a long time and were > exposed to the "optimization" strategies of 20 years ago managed to so > deeply ingest them we still habitually use them. I have to say I wish 4D > was more concerted in suggesting best practices. > > -- > Kirk Brooks > San Francisco, CA > ======================= ********************************************************************** 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] **********************************************************************
