#### Archived

This topic is now archived and is closed to further replies.

# Some hints I kwon and one question

## Recommended Posts

Hi! Here some hints that you maybe kwon, but... just in case : =================== -I have used the GetTickCount Function for the tests, look at the Delphi''s to kwon about this. =================== =================== -I have tested the speed of de CASE against IF ELSE IF ELSE... and you better use CASE, ''couse not only much more clear, if I dont remember bad is about 2 times faster. =================== -And if you want to do something like this: if (i=1) or (i=2) or (i=10) or (i=12) then something You better use something like this: if i in {1,2,10,12} then something The pascal''s "sets" are VERY fast, but they can only have 255 elements. =================== -The FOR and WHILE iteration control routins as long as I try have the spected result... they have equal speed. =================== -Including some assembler code can improve a lot the execution but, as probably you kwon, it can be slower becouse Delphi do several optimizations for his assembler. So in my personal opinion, the use of assember is cool but is not nessesary. =================== -Maybe you are in love with linked lists. Well here are some little tests: Using each element is this: type Pnodo = ^Tnodo ; TNodo = Record value : Integer ; ptr : Pnodo ; end ; * To allocate all the 1000000 elements ("new" function) it delay about 310. * To go from the first one to the last one it takes about 100 * And finally, for dispose all the 1000000 about 410, witch is fine if you think about it. It looks like Linked list are very fast, of course that using arrays is faster (I use arrays) but lists are not bad at all (and this list are not very smart). =============== Well... here is one question: Do you kwon how to do macros in Delphi? I dont mean macros of the keyboard... I mean macros like assembler, where the compiler will NOT do a "CALL" instrucción. Sorry if you dont understand, but maybe you kwon what I saying. I''m asking for this becouse to execute a little Function, for example an integer or real one, the time (prosessor) of this is similar to (parameters + call) the function (+ ret) in self! witch is silly. Well I have make another test too... but these are witch I remember. I hope this long write dont bored you c ya Cocorini

##### Share on other sites
GetTickCount is very innacurate as well

##### Share on other sites
Using the high performance counter to do the tests would provide more accurate results, but the results from GetTickCount are a reasonable guide.

Delphi does not support C-style macros. Inline functions disappeared a few versions back.

You could simulate macros by using the $INC compiler directive, but this would require the macro be in a file all by itself and the code using the macro would need to use the same variable names as the macro. Example: In a text file called AddInt.macro, add the following line z := x + y; and then somewhere in your code procedure SomeProc(x, y: Integer): Integer;var z: Integer;begin {$INC AddInt.macro}  Result := z;end;

This simulates a macro, but is not something that I would use in all my applications.

Steve ''Sly'' Williams  Monkey Wrangler  Krome Studios

##### Share on other sites
First I kwon the GetTickCount is not very good, but is enoght... becouse when I did the tests I did something like this:

i := 12 ;
temp := GetTickCount ;

for t := 1 to 10000000 do
if (i=1) or (i=2) or (i=10) or (i=12) then i := 12 ;

temp := Gettickcount - temp ;

So becouse the "FOR" is very long will not affect that.

And second... Thank you for the "macros"!

c ya
cocorini

##### Share on other sites
I think TimeGetTime is a bit more accurate than GetTickCount (you need to add in MMSystem to your uses clause). Can anyone confirm this?

Alistair Keys

• ### Forum Statistics

• Total Topics
628312
• Total Posts
2982001

• 9
• 9
• 13
• 11
• 13