Vincent Snijders wrote:
Michalis Kamburelis wrote:
I felt that results of this discussion are so important that I created
a page in FPC wiki about it:
http://www.freepascal.org/wiki/index.php/Avoiding_implicit_try_finally_section
There's an URL to mail archives of this discussion, and a small
Michalis Kamburelis wrote:
Are there any other cases where this issue may be significant ? If no,
I'll mark this wiki page clearly as only for FPC earlier than
2004-12-28 (to-be-removed when 2.0 comes in), else I will update it.
(Note: we can continue this talk on wiki page
Vincent Snijders wrote:
Michalis Kamburelis wrote:
Are there any other cases where this issue may be significant ? If no,
I'll mark this wiki page clearly as only for FPC earlier than
2004-12-28 (to-be-removed when 2.0 comes in), else I will update it.
(Note: we can continue this talk on wiki
Michalis Kamburelis wrote:
I suspected that every type that needs to be initialized/finalized
creates such try...finally block,
Yes, it does.
but didn't have time to check. But I
checked it now. OK, page in wiki is changed, and demo program there is
changed.
Talking about TList slowness:
In the last years TList and TStringList became slower and slower. Are there
any alternatives in classes.pp? A simple TList providing only the very basics,
less checks, no notifications, less virtuals, reordered IFs ... ?
I think dynamic arrays are just what you
Michalis Kamburelis wrote:
I felt that results of this discussion are so important that I created a
page in FPC wiki about it:
http://www.freepascal.org/wiki/index.php/Avoiding_implicit_try_finally_section
There's an URL to mail archives of this discussion, and a small demo
program that shows
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 12:13:15 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
[...]
And creates the implicit exception frame only in RaiseIndexError.
I have changed
I'm attaching a simple demo program that shows this. When compiled like
fpc -OG -O2 -Op2 demo_resourcestring_slow.pas
(to get maximum optimizations) sample output of it is
Time of Foo_Normal: 16
Time of Foo_ResourceString: 106
So time difference is really noticeable.
On Fri, 24 Dec 2004, Michalis Kamburelis wrote:
Hi,
I tested your code and found that indeed version in ucopylist is
slightly faster (by about 9.5 / 7 =~ 1.357). Two things:
1. Speedup is only 1.357x, not 3x, like you said. Are you sure that
you're getting 3x speedup ? On what OS and
This is because there is an extra (implicit) Try/Finally block.
Thank you and Peter for answers. This way I was able to see how
try...finally section looks in assembler :) Anyway, I understand that
the answer is can't be speed up. OK, I can live with that.
That is not correct. For your own
Peter Vreman wrote:
This is because there is an extra (implicit) Try/Finally block.
Thank you and Peter for answers. This way I was able to see how
try...finally section looks in assembler :) Anyway, I understand that
the answer is can't be speed up. OK, I can live with that.
That is not correct.
On Fri, 24 Dec 2004, Michalis Kamburelis wrote:
Peter Vreman wrote:
This is because there is an extra (implicit) Try/Finally block.
Thank you and Peter for answers. This way I was able to see how
try...finally section looks in assembler :) Anyway, I understand that
the answer is can't be
Michalis Kamburelis wrote:
Hi,
I tested your code and found that indeed version in ucopylist is
slightly faster (by about 9.5 / 7 =~ 1.357). Two things:
1. Speedup is only 1.357x, not 3x, like you said. Are you sure that
you're getting 3x speedup ? On what OS and with what FPC version are
you
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes, then maybe it's safe to compile parts of FPC
sources in lists.inc (like TList.Get) inside {$IMPLICITEXCEPTIONS OFF} ?
Why not put it into a sub proc:
function
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes, then maybe it's safe to compile parts of FPC
sources in lists.inc (like TList.Get) inside {$IMPLICITEXCEPTIONS
Michael Van Canneyt wrote:
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes, then maybe it's safe to compile parts of FPC
sources in lists.inc (like TList.Get) inside
On Fri, 24 Dec 2004 11:49:10 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes,
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 11:49:10 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt
Hi,
I tested your code and found that indeed version in ucopylist is
slightly faster (by about 9.5 / 7 =~ 1.357). Two things:
1. Speedup is only 1.357x, not 3x, like you said. Are you sure that
you're getting 3x speedup ? On what OS and with what FPC version are you
testing this ? I was doing
19 matches
Mail list logo