Tests I did in 1989 and earlier showed that the null terminated strings
are up to 26 times slower that using PL/I and Pascal strings. And they
are dangerous.
I have put some tests and documentation here:
http://start.oscar-jol.com/fast-c-strings and an early message about the
problem here:
http://start.oscar-jol.com/fast-c-strings/original-message-re-c-strings
Bill Gates had someone reply to me too, and his company's response is at
the bottom of this page: http://start.oscar-jol.com/fast-c-strings
Here's a table showing the relative speeds of various copies. The ASM
copy refers to the 8086 equivalent of the 370 MVC.
I did do some tests on Z/OS when I worked at IBM - however I am unable
to find the results now. They were similar, though!
Essentially, having to search for the binary zero at the end of a string
to find it's length is costing approximately 20 times more CPU power
that doing strings the way PL/I, Pascal and other languages utilise
strings. In addition, C String methods can (and do) overwrite storage
accidentally when a long string is copied to a short string.
Let's fix the problem, once and for all!
Clem Clarke
PS: If the table isn't displayed clearly in this message, please look at
it here:
http://start.oscar-jol.com/fast-c-strings/original-message-re-c-strings
----------------------------------------
__________________________________________________________________
| |
| Elapsed Time for DUMMY CPY (Loop Overhead) 2.00 |
| |
| Elapsed Time for ASM CPY is 7.00 |
| |
| Elapsed Time for MEMCPY CPY is 12.00 |
| |
| Elapsed Time for STRCPY CPY is 31.00 |
| |
| Elapsed Time for INCRCPY (Slowest) CPY is 136.00 |
| |
| Elapsed Time for INCRCPY (using Register Vars) CPY is 67.00 |
|__________________________________________________________________|
| |
| Type of Copy Elap Loop Real Ratio |
| Time Overhd Copy |
|__________________________________________________________________|
| |
| Copying a 66 byte string 300000 times |
| ===================================== |
| |
| INCRCPY (Static Pointers) 136.00 2.00 134.00 1.000000 |
| INCRCPY (Register Pointers) 67.00 2.00 65.00 2.061538 |
| STRCPY 31.00 2.00 29.00 4.620690 |
| MEMCPY 12.00 2.00 10.00 13.400000 |
| ASM 7.00 2.00 5.00 26.800000 |
| ^ |
| | |
| Note -------------------------------------------------| |
|__________________________________________________________________|
Robin Vowels wrote:
From: "Paul Gilmartin" <00000014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Wednesday, January 31, 2018 3:48 PM
On 2018-01-30, at 21:17:05, Robin Vowels wrote:
On 31/01/2018 3:27 AM, Jon Perryman wrote:
Exactly my point. I suspect that the C group considered
Null-terminated strings cost exactly the same as fixed length
fields. ...
But if you just want the length, a fixed-length string wins.
In PL/I, a varying-length string also wins, because the current length
is kept with descriptor, so it isn't necessary to search through the
string in order to find the end.
And strings with descriptors (address, length) make it easy to define
substrings. Just create a new descriptor. A C partisan once told
me, just save a character, overlay it with a NUL, then put it back
when you're done with the substring.
I've used a language that defined substrings by creating descriptors,
then handled garbage collection properly -- any byte not governed by
one or more descriptors was subject to reclaim.
That is how strings are implemented in XPL (from c. 1966).
A substring was obtained by merely pointing a descriptor
at the first character ; the required number of characters
being inserted in the descriptor.
No characters of the string were moved.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
