I Know macros are the compiler simply replacing the source code before the real compileing process appear.
I know to large functions procedures must take place and to the smaller onces a macro can be much faster. But when is it a large function and need procedure?
Asking about speed and size.
Regards
Macro VS. Procedures?
-
ToastEater
- User

- Posts: 49
- Joined: Tue Jul 25, 2006 5:07 pm
Macro VS. Procedures?
Sorry for my damn english
amour au PB et au traducteur de google d'ofcourse
amour au PB et au traducteur de google d'ofcourse
-
kinglestat
- Enthusiast

- Posts: 746
- Joined: Fri Jul 14, 2006 8:53 pm
- Location: Malta
- Contact:
Hi ToastEater,
As in most things in life I guess its a question of balance and control
And as a decision is more likely to emerge when optimizing your code
I think sometimes its more worth avoiding stuff like multiple-dimensional arrays and anything which is beyond your control to really optimize.
I'm a new user to PureBasic....but I'm a 2nd generation core C programmer, where my job was to optimize (other programmers) code. I have seen that many of the old "tricks" are hardly used any more but with some thought you can truly speed things up
Eg strings are a crippler as they are not native to any processor. Fastest operations are with longs usually 1-3 clock cycles with CISC processors. Thus using a pointer to a string when doing many opeartions on string help (eg sorting an array of pointers as opposed to sorting an array oof strings)
of course as a wise man once said
opinions are like assholes...everybody's got one
and pardon my french
As in most things in life I guess its a question of balance and control
And as a decision is more likely to emerge when optimizing your code
I think sometimes its more worth avoiding stuff like multiple-dimensional arrays and anything which is beyond your control to really optimize.
I'm a new user to PureBasic....but I'm a 2nd generation core C programmer, where my job was to optimize (other programmers) code. I have seen that many of the old "tricks" are hardly used any more but with some thought you can truly speed things up
Eg strings are a crippler as they are not native to any processor. Fastest operations are with longs usually 1-3 clock cycles with CISC processors. Thus using a pointer to a string when doing many opeartions on string help (eg sorting an array of pointers as opposed to sorting an array oof strings)
of course as a wise man once said
opinions are like assholes...everybody's got one
and pardon my french
-
ToastEater
- User

- Posts: 49
- Joined: Tue Jul 25, 2006 5:07 pm
hehehekinglestat wrote:Hi ToastEater,
As in most things in life I guess its a question of balance and control
And as a decision is more likely to emerge when optimizing your code
I think sometimes its more worth avoiding stuff like multiple-dimensional arrays and anything which is beyond your control to really optimize.
I'm a new user to PureBasic....but I'm a 2nd generation core C programmer, where my job was to optimize (other programmers) code. I have seen that many of the old "tricks" are hardly used any more but with some thought you can truly speed things up
Eg strings are a crippler as they are not native to any processor. Fastest operations are with longs usually 1-3 clock cycles with CISC processors. Thus using a pointer to a string when doing many opeartions on string help (eg sorting an array of pointers as opposed to sorting an array oof strings)
of course as a wise man once said
opinions are like assholes...everybody's got one
and pardon my french
I know i know but mean how long time does it take to the function like
jmp myfunction ; should i do this? and how long does it take to jump to myfunction: label
..
..
.. ; or should i just do my few lines code here
myfunction:
..
..
..
Retn
I know how to program very small lines of assembler, but haven't seen anything there was converted to asm there would use a function
sorry again and always for my bad english
Thanks a ton
Sorry for my damn english
amour au PB et au traducteur de google d'ofcourse
amour au PB et au traducteur de google d'ofcourse