Re: The speed penalty for pointers is pretty low compiled

[Kirk Brooks via 4D_Tech]

Hey Wayne,

On Thu, Nov 30, 2017 at 1:10 PM, Wayne Stewart via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> ​> ​Agreed again. I really do wish 4D did a better job of presenting new
> ​ ​
> technology.​
>
> ​Not wanting to sound like a 4D shill but I think the new blog (
> https://blog.4d.com) is fantastic for demonstrating new features.
>

​You are absolutely correct. Thanks for pointing that out.
Ha, I wind up doing exactly the sort of thing I'm saying not to do.​


-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**

Re: The speed penalty for pointers is pretty low compiled

[Wayne Stewart via 4D_Tech]

​Kirk,

​> ​
Agreed again. I really do wish 4D did a better job of presenting new
​ ​
technology.​

​Not wanting to sound like a 4D shill but I think the new blog (
https://blog.4d.com) is fantastic for demonstrating new features.


Regards,

Wayne


[image: --]
Wayne Stewart
[image: http://]about.me/waynestewart



On 1 December 2017 at 05:05, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Hey Jody,
> Great post.
>
> On Thu, Nov 30, 2017 at 7:43 AM, Jody Bevan via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
> > 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.
> >
> ​True but there's retro code that while working and stable is also
> un-necessary any more or simply overly complicated because it's relying on
> procedures written prior to certain capabilities 4D even had. I wonder how
> many folks are still using the old drag and drop commands for instance.
>
>
> > 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.
>
> ​I agree. I've re-written the main db our company uses three times now in
> the last 14 years. Started in 6.8, then jumped to 2004 and then to v13. The
> one from '04 to v13 was ​hard. In my case mainly because I took that
> opportunity to correct some structural issues that had come up as the scope
> of the project increased. It just had to be done. And the benefits are
> worth it.
>
> The size of the code base actually shrank. When you implement the newer
> functions 4D offers it frequently makes for less code to accomplish the
> same things. It also allowed me to position the project to interact more
> with other services. The user experience improves and I'm better able to
> keep it looking a little more modern than a lot of 4D looks. That's more
> important than mere aesthetics. The more I can make my interfaces resemble
> the sort of interfaces they see in their browsers the easier it is for them
> to use my program.
>
>
> > 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.
> >
> ​Agreed again. I really do wish 4D did a better job of presenting new
> technology. And how they intend us to use it as a place to start. Or
> perhaps more to the point how to transition to it. And why. Again I'll
> point back to the drag and drop stuff. I recall posting something about how
> to implement the new form events and the pasteboard but I was looking at it
> from the context of working with the old commands and trying to understand
> how adding the new capabilities was a benefit. ​
> ​Which was a complete waste of time​. Finally someone, probably Miyako or
> Josh, flatly told me "just walk away from the old way of doing it - you
> don't need it anymore." Duh! Light bulb moment. I'm paraphrasing and it was
> probably nicer but that's what I needed to hear to ditch my old way of
> looking at it and start fresh.
>
> Personally I think 4D walks a tight line on that sort of stuff - not
> wanting to alienate old projects or make it seem like they _have_ to be
> re-written. And then, as you say, we've all be bitten by jumping onto
> something new only to stumble on to some bug. Well, you know what they say,
> if it was easy to write good code every a**hole in the world would be doing
> it.
>
> --
> Kirk Brooks
> San Francisco, CA
> ===
>
> *The only thing necessary for the triumph of evil is for good men to do
> nothing.*
>
> *- Edmund Burke*
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.htm

Re: The speed penalty for pointers is pretty low compiled

[Kirk Brooks via 4D_Tech]

Hey Jody,
Great post.

On Thu, Nov 30, 2017 at 7:43 AM, Jody Bevan via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> 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.
>
​True but there's retro code that while working and stable is also
un-necessary any more or simply overly complicated because it's relying on
procedures written prior to certain capabilities 4D even had. I wonder how
many folks are still using the old drag and drop commands for instance.


> 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.

​I agree. I've re-written the main db our company uses three times now in
the last 14 years. Started in 6.8, then jumped to 2004 and then to v13. The
one from '04 to v13 was ​hard. In my case mainly because I took that
opportunity to correct some structural issues that had come up as the scope
of the project increased. It just had to be done. And the benefits are
worth it.

The size of the code base actually shrank. When you implement the newer
functions 4D offers it frequently makes for less code to accomplish the
same things. It also allowed me to position the project to interact more
with other services. The user experience improves and I'm better able to
keep it looking a little more modern than a lot of 4D looks. That's more
important than mere aesthetics. The more I can make my interfaces resemble
the sort of interfaces they see in their browsers the easier it is for them
to use my program.


> 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.
>
​Agreed again. I really do wish 4D did a better job of presenting new
technology. And how they intend us to use it as a place to start. Or
perhaps more to the point how to transition to it. And why. Again I'll
point back to the drag and drop stuff. I recall posting something about how
to implement the new form events and the pasteboard but I was looking at it
from the context of working with the old commands and trying to understand
how adding the new capabilities was a benefit. ​
​Which was a complete waste of time​. Finally someone, probably Miyako or
Josh, flatly told me "just walk away from the old way of doing it - you
don't need it anymore." Duh! Light bulb moment. I'm paraphrasing and it was
probably nicer but that's what I needed to hear to ditch my old way of
looking at it and start fresh.

Personally I think 4D walks a tight line on that sort of stuff - not
wanting to alienate old projects or make it seem like they _have_ to be
re-written. And then, as you say, we've all be bitten by jumping onto
something new only to stumble on to some bug. Well, you know what they say,
if it was easy to write good code every a**hole in the world would be doing
it.

-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**

Re: The speed penalty for pointers is pretty low compiled

[Jody Bevan via 4D_Tech]

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. 




> On Nov 28, 2017, at 9:17 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Arnaud,
> 
> On Tue, Nov 28, 2017 at 1:26 AM, Arnaud de Montard via 4D_Tech <
> 4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: The speed penalty for pointers is pretty low compiled

[Kirk Brooks via 4D_Tech]

Arnaud,

On Tue, Nov 28, 2017 at 1:26 AM, Arnaud de Montard via 4D_Tech <
4d_tech@lists.4d.com> 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
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**

Re: The speed penalty for pointers is pretty low compiled

[Arnaud de Montard via 4D_Tech]

> Le 28 nov. 2017 à 02:06, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> a 
> écrit :
> 
> I still have a lingering sense that using pointers to variables imposes a
> noticeable speed penalty on code execution time. It's an old sense. 

Hi Kirk, 
thanks for that test. I had the same feeling that pointers are more and more 
fast. 

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. 

-- 
Arnaud de Montard 



**
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
**

The speed penalty for pointers is pretty low compiled

[Kirk Brooks via 4D_Tech]

I still have a lingering sense that using pointers to variables imposes a
noticeable speed penalty on code execution time. It's an old sense. I was
just thinking about it while using a simple method I have for doing
Increments. It's called Increment, takes a pointer to a var and adds 1 to
it.

$1->:=$1->+1


​Because we don't have += in 4D. I don't know why.

I wondered how much time it takes to de-reference the pointer. I wrote a
couple of loops and iterated 100k times. Interpreted the difference was
larger than I expected.

$n:=$n+1~49ms
Increment(->$n)  ~3800ms​


​Ok, I thought, so for a loop like that I stick to direct referencing the
vars. How much effect does compiling have? A lot.

​$n:=$n+1~0ms
Increment(->$n)  ~50ms​


This is with v15.5 running on a 1 year old MacBookPro. ​
​Ten iterations per test case.
​
So it's true using pointers instead of directly referencing variables takes
more time. Of course we're talking about 100k operations here. That would
really matter on large calculations performed 100s of times. For anything
involving direct interface with the user, though, I don't think it's really
a factor.

BTW, you can get around the 'pointer penalty' by using local vars directly
and then copying the results to the pointed to object. This makes a
noticeable difference if you are doing things like filling arrays on the
server. Say I've got a method to look up some stuff and then populate 5
arrays which I pass to the method as pointers. At size it becomes faster to
declare the arrays in the method, fill them and then use COPY ARRAY to copy
to the pointed to arrays.

-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**