L wrote:
Why is the first and third example *so* much faster than the second example?
Significantly faster.
Because you doubled the number of string concatenations.
Vincent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fr
> L wrote:
> > Why is the first and third example *so* much faster than the second example?
> > Significantly faster.
> >
>
> Because you doubled the number of string concatenations.
>
> Vincent.
Right, but it's not twice as slow :-) Worse... It's at least 50-100 times
slower.
Weird.
I will hav
At 09:46 19-11-2005, you wrote:
> L wrote:
> > Why is the first and third example *so* much faster than the second
example?
> > Significantly faster.
> >
>
> Because you doubled the number of string concatenations.
>
> Vincent.
Right, but it's not twice as slow :-) Worse... It's at least 50-1
L505 wrote:
L wrote:
Why is the first and third example *so* much faster than the second example?
Significantly faster.
Because you doubled the number of string concatenations.
Vincent.
Right, but it's not twice as slow :-) Worse... It's at least 50-100 times
slower.
Weird.
I will hav
- Original Message -
From: "Peter Vreman" <[EMAIL PROTECTED]>
To: "FPC-Pascal users discussions"
Sent: Saturday, November 19, 2005 1:47 AM
Subject: Re: [fpc-pascal] Speed question for strings
> At 09:46 19-11-2005, you wrote:
> > > L wrote:
> > > > Why is the first and third example *so
> The first string is always long, so you are doing twice adding a small
> string to a long string. This causes much heap fragmentation.
>
> Try result:= result + (Line + #13#10);
> or
>
> Line := Line + #13#10;
> Result := Result + Line;
Ahh that will probably do the trick. I'll let you know.
>
Micha Nelissen wrote:
On Fri, 18 Nov 2005 13:18:40 -0800 (PST)
Alan Mead <[EMAIL PROTECTED]> wrote:
fpc 2.0.0 doesn't compile this... are "for..in" loops in a newer
version or will they be sometime soon? Here is a little blurb about
FPC will never support this, AFAIK. It doesn't really ad
I sent Wednesday this request also but perhaps it wasn't seen.
I was able to launch fp and read in the example progralm HelloWorld.
However, this program (and any other program) will compile as the error
is:
Fatal: Can't find unit System
But when I look in fpc.cfg the path for units is correct:
#
> On Fri, 18 Nov 2005 13:18:40 -0800 (PST)
> Alan Mead <[EMAIL PROTECTED]> wrote:
>
> > fpc 2.0.0 doesn't compile this... are "for..in" loops in a newer
> > version or will they be sometime soon? Here is a little blurb about
>
> FPC will never support this, AFAIK. It doesn't really add anything
> I sent Wednesday this request also but perhaps it wasn't seen.
> I was able to launch fp and read in the example progralm HelloWorld.
> However, this program (and any other program) will compile as the error
> is:
> Fatal: Can't find unit System
> But when I look in fpc.cfg the path for units is
I was also wondering HOW it would be done, but I just assumed that
everything was easy for you guys :)
Would it be hard for the compiler to try to automatically convert
this new construct into an equivalent older one? .. So when it finds
for S in ArrayOfInteger do ...
it silently converts it to
Which is faster, reading a file Character by Character, by Memory Block, or by
StringList.text?
Welcome to the CPU war for StrLoadFile.. Please wait...
test 1 execution time: 9356007 <-- char by char
test 2 execution time: 259683 <-- block
12 matches
Mail list logo
