Difference between revisions of "Avoiding implicit try finally section"
From Free Pascal wiki
Jump to navigationJump to search (Page created, with link to discussion in fpc-devel archives and demo source code) |
(Minor changes for clarity) |
||
Line 1: | Line 1: | ||
− | Sometimes it's important to know that compiler can wrap some code in implicit try ... finally section. In some cases this can significantly affect the speed of given code | + | Sometimes it's important to know that compiler can wrap some code in implicit try ... finally section. In some cases this can significantly affect the speed of given code. |
Here's a link to archived discussion on fpc-devel list regarding this issue, with subject "TList slowness in classes" : http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg01367.html | Here's a link to archived discussion on fpc-devel list regarding this issue, with subject "TList slowness in classes" : http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg01367.html | ||
− | And | + | And below is a small demo program that |
* Shows a trick how to avoid implicit try ... finally block (without changing the meaning or safety of the code) in some cases. | * Shows a trick how to avoid implicit try ... finally block (without changing the meaning or safety of the code) in some cases. | ||
* When run, this program clearly shows that avoiding an implicit try ... finally block can make code a lot faster. When I run this program on my system, I get | * When run, this program clearly shows that avoiding an implicit try ... finally block can make code a lot faster. When I run this program on my system, I get |
Revision as of 09:22, 25 December 2004
Sometimes it's important to know that compiler can wrap some code in implicit try ... finally section. In some cases this can significantly affect the speed of given code.
Here's a link to archived discussion on fpc-devel list regarding this issue, with subject "TList slowness in classes" : http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg01367.html
And below is a small demo program that
- Shows a trick how to avoid implicit try ... finally block (without changing the meaning or safety of the code) in some cases.
- When run, this program clearly shows that avoiding an implicit try ... finally block can make code a lot faster. When I run this program on my system, I get
Time of Test_ResourceString: 107 Time of Test_ResourceString_Faster: 16
{$mode objfpc} uses {BaseUnix, Unix needed only to implement Clock} BaseUnix, Unix, SysUtils; function Clock: Int64; var Dummy: tms; begin Clock := FpTimes(Dummy); end; resourcestring SResString = 'blah blah blah blah blah blah blah blah blah blah'; { Note that Test_ResourceString and Test_ResourceString_Fast do exactly the same thing. } procedure Test_ResourceString(i: Integer); begin if i = -1 then raise Exception.Create(SResString); end; procedure Test_ResourceString_Faster(i: Integer); procedure RaiseError; begin raise Exception.Create(SResString) end; begin if i = -1 then RaiseError; end; { Note that when I call Test_ResourceString and Test_ResourceString_Fast i is always >= 0 so Exception is never actually raised. } const TestCount = 10000000; var i: Integer; Start: Int64; begin Start := Clock; for i := 0 to TestCount do Test_ResourceString(i); Writeln('Time of Test_ResourceString: ', Clock - Start); Start := Clock; for i := 0 to TestCount do Test_ResourceString_Faster(i); Writeln('Time of Test_ResourceString_Faster: ', Clock - Start); end.