Jump to content
  • Advertisement


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


Some hints I kwon and one question

This topic is 6096 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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 this post

Link to post
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.


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;
z: Integer;
{$INC AddInt.macro}
Result := z;

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

Steve ''Sly'' Williams  Monkey Wrangler  Krome Studios

Share this post

Link to post
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

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!