0

I've read that performance-wise character arrays are better/faster than std::string. But personally I find using std::string much easier.

I'm currently writing some database APIs which will be fetching/inserting data into the database. In these APIs, I want to use std strings, but I'm not sure how much penalty in performance will I pay due to my choice. My APIs will query the database, therefore, network IO will be involved.

Is the performance penalty much lesser than the network latency(~10 ms), because in that case, I would happily like to use std::string.

Vishal Sharma
  • 1,248
  • 14
  • 39
  • 2
    `std::string` *is* a character array. It just has an actual API that you don't have to reimplement every single time you want to use it. – Quentin Jun 26 '19 at 07:51
  • 1
    The penalty shouldn't be that big. IIRC even appending to it has an amortized constant runtime. If you know the size in advance and want to avoid having to reallocate, there's a "fill constructor" and various other constructors that take a `char*` and copy the content or similar. – Blaze Jun 26 '19 at 07:52
  • @Blaze can that penalty be quantified somehow? When I'm having discussion about which one to chose, I can't convince someone to use std::string by telling them that there will only be 'a very small penalty'. I think without quantifying the penalty in some way, it's hard to argue because sometimes people are worried more about the performance and they are ready to sacrifice the ease in management for that. – Vishal Sharma Jun 26 '19 at 07:56
  • 1
    IMHO, You have to use std::string_view / and const char* until you need to take the value and transfer this value to another part of you application. Depending on the number of string of your queries, you may gain some new/delete call. – Gojita Jun 26 '19 at 07:58
  • What you have read is incorrect. Or incomplete, or a false generalisation, or whatever you want to call it. It might be that in some particular case std::string is not the fastest option out there. But to know if that applies to your case, you'd first have to *measure* whether it makes a noticable difference at all. It's pretty much the only reliable way to tell whether it matters for your case. – stijn Jun 26 '19 at 07:58
  • Possible duplicate of [Meaning of acronym SSO in the context of std::string](https://stackoverflow.com/questions/10315041/meaning-of-acronym-sso-in-the-context-of-stdstring) – Henri Menke Jun 26 '19 at 07:59
  • 2
    @VishalSharma my suggestion is to write a small demo that does a bunch of fetching/inserting with somewhat realistic data. Have one version using just `char` arrays and one that uses `std::string`, then measure the time they take. – Blaze Jun 26 '19 at 08:02
  • @HenriMenke from what I could understand from the link you've provided, it seems that for smaller length strings(where length is platform dependent), std::string will perform exactly like char arrays because both will be stack allocated. However there will be degradation in the performance when that, platform dependent length, is exceeded. Am I right in my understanding? – Vishal Sharma Jun 26 '19 at 08:07
  • I would expect a good way to begin is with template methods that make use of `Iterator` concept. That way you can process the data given in a `begin`-`end` range and then write utility functions that take string/vector or whatever and pass it to the actual implementation that does the work via iterators. This will allow you to use a vector or whatever where performance matters and use the convenient `std::string` where it does not. – Etherealone Jun 26 '19 at 08:09
  • @VishalSharma Yes, but you have to be careful with stack-allocated string, because stack space is very limited. That is why `std::string` comes with the small-string optimization that allocates on the heap once a certain length is exceeded. If you need more in-situ capacity have a look at Folly's [`fbstring`](https://github.com/facebook/folly/blob/master/folly/FBString.h). – Henri Menke Jun 26 '19 at 08:14
  • 1
    For goodness sake, use `std::string` instead of `char*` whenever you can! In my mind, the only scenario where resorting to `char*` makes sense is on heavily resource-constrained systems (microcontrollers,...), esp. when dynamic memory allocation is problematic. – JimmyB Jun 26 '19 at 09:55

2 Answers2

7

As with nearly all performance questions, the answer is to measure. Modern std::string implementations are very likely not going to be the bottleneck on inserting data into a database. Until you have profiling data that suggests that they are, you're probably best off not worrying about it.

Nathan Rogers
  • 424
  • 1
  • 4
3

You asked:

Is the performance penalty much lesser than the network latency(~10 ms), because in that case, I would happily like to use std::string.

The blunt answer is Yes.

A quick compare of const char* vs. std::string :

const char* pros:

uses a little less space since it doesn't store the size of the string. This is about the only advantage I can come up with atm. performance wise.

std::string pros:

stores the size of string, this is generally better since it means not having to scan through the string to know the size, etc... (and to avoid copies use const std::string&)

std::string is basicly that: a const char* and a size_t (the size/lenght of the string) if you ignore what is called "small string optimization" (another advantage - look it up yourself)

So I wouldn't worry about performance (if everything is handled properly) - my advice: stop worrying about performance - do some testing and a profiling and see what shows up in the profiler. That being said - knowing how 'stuff' works and performs is good thing.

darune
  • 9,436
  • 1
  • 16
  • 47