Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #19587

Re: Alternative libraries for C, that are efficient

Show all headers | View raw

Barry Schwarz wrote:
) On Thu, 12 Apr 2012 09:01:40 -0700 (PDT), John Reye
)<jononanon@googlemail.com> wrote:
)
)>Hi,
)>
)>recently I learned that various "standard C library" functions have
)>deficiencies in terms of high performance.
)
) Have you actually measured the performance impact of calling strlen
) after each fgets?
)
)>Examples include the return values of fgets(), strcpy(), strcat()
)>(thanks Eric Sosman for mentioning the last 2)
)>
)>Example:            char * strcat ( char * destination, const char *
)>source );
)>Return Value:     destination is returned.
)>
)>How useless is that! I already know the distination, in the first
)>place.
)
) Useless is in the eye of the beholder.
)
)     char buffer[100] = "The input is ";
)     puts(strcat(buffer, flag ? "valid" : "invalid");

Not much difference there:

  char buffer[100] = "The input is ";
  strcat(buffer, flag ? "valid" : "invalid");
  puts(buffer);

You only have to type the variable name twice.
That's a very minor inconvenience.  So it's marginally useful.
Returning a pointer to the nul terminator would be a lot more useful.

) or
)
)    strcat(strcpy(new_large_buffer, 
)                        original_text_in_small_buffer),
)              additional_text);

If strcpy and strcat returned a pointer to the nul character at the end of
the string, that would still work, *and* it would be a lot more efficient.

I've seen code where they build a giant string by repeatedly strcat()ing
a few words on the end.  That's needless O(n^2) performance right there.

)>Why not return a pointer to the end of the concatenated string, or the
)>size of the string. This would cost the library no extra performance
)>cost whatsoever!
)
) Was that true 25+ years ago when the language was being designed?

Yes.  Duh.  It's *NO* performance loss.  Not negligible, but zero.  Nil.
The library just copied a number of characters to somewhere else.
And it added a trailing zero to boot.  So it knows where that zero went.

)>Are these deficiencies _only_ string-related?
)>Is there no good library which I can use for optimal computing?
)
) Any library where fgets returns something other the destination
) pointer would be non-portable in the extreme.  Some might be tempted
) to say it is not even C.
)
) The approach taken by some compiler writers when they need to tweak a
) standard function (such as add an extra parameter to make it safer) is
) to create a new function with a similar name that is reserved for the
) implementation (such as prepending an _ or appending a _s).  Then the
) user has the choice of using the standard function or the system
) specific extension.

I think gnu libc has a few of those.  It would have been an easy fix
to accept those extra functions into the C standard interface, and then
everybody would have been happy.

)>Surely there must be a good library somewhere, or do all C programmers
)>really carry their own routines with them?
)
) Most suffer these horrendous performance problems in silence by using
) the standard library.  Others have been known to write their own
) wrapper functions to encapsulate the standard functions.  But this is
) usually done to add functionality (such as common error checking)
) rather than deal with undocumented performance issues.

The best approach I've seen is to have the build script check for
platform-specific extensions (such as strlcpy and strlcat), and if
those don't exist, include wrappers which emulate their behaviour.


I believe that these functions return the original pointer because
the language designers had some half-assed idea about viewing strings
as some kind of opaque type that you could manipulate through functions.
(I.E. conceptually, strcat takes two strings and returns one string,
 if you conveniently forget that the first string is changed, and also
 needs to have enough memory backing it to hold the whole string.)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:01 -0700
  Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 09:05 -0700
    Re: Alternative libraries for C, that are efficient ImpalerCore <jadill33@gmail.com> - 2012-04-12 09:38 -0700
      Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:32 -0700
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 14:41 -0400
          Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 18:51 +0000
            Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:46 -0700
              Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-13 14:51 +0000
            Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:38 -0400
              Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 19:47 +0300
  Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 09:09 -0700
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:13 -0700
      Re: Alternative libraries for C, that are efficient tom st denis <tom@iahu.ca> - 2012-04-12 18:20 -0700
  Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-12 18:13 +0200
    Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:47 -0400
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:22 -0700
      Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 22:37 +0200
        Re: Alternative libraries for C, that are efficient Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-04-15 20:15 +0300
          Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-15 23:30 +0200
  Re: Alternative libraries for C, that are efficient Ben Pfaff <blp@cs.stanford.edu> - 2012-04-12 09:20 -0700
  Re: Alternative libraries for C, that are efficient Noob <root@127.0.0.1> - 2012-04-12 18:34 +0200
    Re: Alternative libraries for C, that are efficient Kaz Kylheku <kaz@kylheku.com> - 2012-04-12 18:00 +0000
      Re: Alternative libraries for C, that are efficient nick_keighley_nospam@hotmail.com - 2012-04-13 03:50 -0700
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:24 -0700
      Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-12 13:08 -0700
  Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 12:50 -0400
    Re: Alternative libraries for C, that are efficient John Reye <jononanon@googlemail.com> - 2012-04-12 11:30 -0700
      Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 15:55 -0400
  Re: Alternative libraries for C, that are efficient Barry Schwarz <schwarzb@dqel.com> - 2012-04-12 11:41 -0700
    Re: Alternative libraries for C, that are efficient Willem <willem@toad.stack.nl> - 2012-04-12 19:08 +0000
  Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-12 21:07 +0100
    Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-12 20:35 -0400
      Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 11:38 +0100
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 09:52 -0400
          Re: Alternative libraries for C, that are efficient "BartC" <bc@freeuk.com> - 2012-04-13 17:56 +0100
      Re: Alternative libraries for C, that are efficient Kenneth Brody <kenbrody@spamcop.net> - 2012-04-13 12:56 -0400
        Re: Alternative libraries for C, that are efficient James Kuyper <jameskuyper@verizon.net> - 2012-04-13 14:48 -0400
          Re: Alternative libraries for C, that are efficient Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-14 07:22 -0700
  Re: Alternative libraries for C, that are efficient Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-12 21:23 -0400
    Re: Alternative libraries for C, that are efficient Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-04-13 16:52 +0000
  Re: Alternative libraries for C, that are efficient Jens Gustedt <jens.gustedt@loria.fr> - 2012-04-13 23:24 +0200

csiph-web