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
Mailing lists / fpc-pascal / 2018-07
FPC_PCHAR_LENGTH dog slow
6 messages · 5 people ·
- Unknown author 2
- leledumbo 1
- Mattias Gaertner 1
- Ryan Joseph 1
- Tomas Hajny 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
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.
Mattias
I was just parsing something and found that a call to length on a pchar was taking 90+%…
Ryan Joseph wrote 6 lines
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 indeed the difference between Pascal strings (Short/Ansi/Wide/UnicodeString) and C-like PChars.
Tomas
Tomas Hajny wrote 5 lines
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 PChars.
absolutely! i truly hated having to add loops to my string handling code when working with ""C strings"" as we used to call them back in the day... the huge advantage of "Pascal strings" is their length being specified at the beginning of the character array they are stored in...
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-)
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list unless*
*a signed and pre-paid contract is in effect with us.*
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.
leledumbo wrote 5 lines
> 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.
excellent... i've been confused by all the various string changes that have been made in the recent years since i joined the lists... the UTF stuff really spun my head around with all the various discussions and arguments... i'm still not sure i understand it... i don't need UTF but i hope that my newer programs are written properly to handle UTF if it ever comes up... they're generally console applications reading textual data from elsewhere and processing for local output...
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list unless*
*a signed and pre-paid contract is in effect with us.*