FPC_PCHAR_LENGTH dog slow

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

FPC_PCHAR_LENGTH dog slow

Ryan Joseph
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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC_PCHAR_LENGTH dog slow

Tomas Hajny-2
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 indeed the difference between Pascal strings
(Short/Ansi/Wide/UnicodeString) and C-like PChars.

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC_PCHAR_LENGTH dog slow

Mattias Gaertner
In reply to this post by Ryan Joseph
On Tue, 3 Jul 2018 09:15:16 -0600
Ryan Joseph <[hidden email]> 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.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC_PCHAR_LENGTH dog slow

wkitty42
In reply to this post by Tomas Hajny-2
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 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.*
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC_PCHAR_LENGTH dog slow

Free Pascal - General mailing list
> 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 from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC_PCHAR_LENGTH dog slow

wkitty42
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
> 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.*
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal