Originally Posted by
User137
You create TStopWatch 22 times, but never free it. It is memory leak. Also i guess more interesting numbers come if StopWatch was used outside the "for I" loop. What kind of numbers do you get?
Since TStopWatch isn't a class but is actually a record with lots of class helper methods I'm not creating a memory leak.
Becouse TStopwatch is record the memory for it gets reserved when entering Mutton1OnClick method. You need to call Stopwatch.StartNow so that initial parameters of StopWatch are being set (automatic chosing of best way for time profiling based on hardware and OS capablitity, resetting timer, etc.).
Using the StopWatch outside "for I loop" still shows same difference in performance. Now I did find an error in my usage of StopWatch. I was retrieving Milliseconds with ElapsedTime.Milliseconds which returns only milliseconds part but I should have been using ElapsedTime.TotalMilliseconds to retrieve whole elapsed time in Milliseconds.
Originally Posted by
User137
Also because of the caused function parameter load, compiler optimization might do things. Optimization might "inline" automatic if constants were used
Code:
procedure TWorldData.SetData(const X, Y, Z: Integer; const Position: T3Dposition); //inline; ?
You can't use that in Getter or Setter property methods.
Originally Posted by
User137
Even the GetData allocates and sets 12 bytes for 3 integers for each pos, while nested for-loops do not.
Booth enumerator and nested for loops aproach retrieve data through the use of property so in both cases GetData is being called. I have written my code specifically to do so in order for me to have realistic comparison.
Anywhay I managed to improve the overal performance a bit by removing direct typecasting like:
Code:
result := TWorldData(FOwner).Data(FXPos,FYPos,FZPos)
I gues that lower performance I get with my Enumerator implementation is due to using another class which acts as annother abstract layer. Unfortunately you can't do without this aditional abstract level.
Bookmarks