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.

Reply via email to