On 07/03/2018 01:44 PM, leledumbo via fpc-pascal wrote:
i think i'm still waiting for the string "length byte" becoming a "length
word" or possibly a "length long" so the speed of pascal strings can be
reacquired -=B-) >
Ansi and any other dynamic strings already have length longint that allows
> i think i'm still waiting for the string "length byte" becoming a "length
word"
or possibly a "length long" so the speed of pascal strings can be reacquired
-=B-)
Ansi and any other dynamic strings already have length longint that allows
2GB string length with O(1) length retrieval.
--
Sent
On 07/03/2018 12:01 PM, Tomas Hajny wrote:
On Tue, July 3, 2018 17:15, Ryan Joseph wrote:
Why is that so crazy slow? Does it need to iterate the entire length of the
string to know it’s length? >
Yes, that's indeed the difference between Pascal strings
(Short/Ansi/Wide/UnicodeString) and C-like
On Tue, 3 Jul 2018 09:15:16 -0600
Ryan Joseph wrote:
> I was just parsing something and found that a call to length on a pchar was
> taking 90+% of the time in FPC_PCHAR_LENGTH.
>
> Why is that so crazy slow? Does it need to iterate the entire length of the
> string to know it’s length?
Yes.
On Tue, July 3, 2018 17:15, Ryan Joseph wrote:
> I was just parsing something and found that a call to
> length on a pchar was taking 90+% of the time in
> FPC_PCHAR_LENGTH.
>
> Why is that so crazy slow? Does it need to iterate the
> entire length of the string to know it’s length?
Yes, that's in
I was just parsing something and found that a call to length on a pchar was
taking 90+% of the time in FPC_PCHAR_LENGTH.
Why is that so crazy slow? Does it need to iterate the entire length of the
string to know it’s length?
Regards,
Ryan Joseph
