Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
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.
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.
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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I'm coding a little HTTP 1.1 web server in C++98 (c++ version mandated by my school) and i haven't make a decision about which data type i'm gonna use to perform the request parsing, and how.
Since i'll be receiving read-only (by read-only i mean that i don't have to modify the buffer) data from a user-agent, would it make sense to use std::string to store the incoming data ?
HTTP syntax is very straightforward, and can be parse using a finite state machine. Iterating over a const char * seems enough and doesn't make any allocations, i can use buffer that recv gives me.
On the other hand, i could use std::string facilities like find and substr to parse the request, but that would lead to memory allocations.
My server doesn't need to be as efficient as nginx, but i'm still worried about the performance of my application.
I'm eager to know your thoughts.
Definitely. It's a school project, not a high-performance production server (in which case you'd be using a more modern C++ variant).
The biggest performance problem you'd typically have with std::string is not parsing, but string building. a + b + c + d + e can be rather inefficient. Details, really: just start by writing a correct implementation, and then see which parts are too slow in testing. There are very few projects, even in commercial software development, where that's not the right approach.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I heard that less dimensions is better, but is it worth it to change from method B (that i already use) to A?
What is the most optimal way of using array variables?
Example code in C
Method A:
int var1[5][10][5][4];
int var2[5][10][5][4];
int var3[5][10][5][4];
Method B:
int var4[3][5][10][5][4];
I think that if something is "better" or not depends a lot on the perspective, e.g. performance, readability, maintainability, consistency, and probably many more. There is probably no clear answer to your question, and every answer might be opinion based.
Anyway, you could "mix" both approaches, having separate variables that "view" slices of the "many-dimension"-array. Then you could pick the "best" approach for the respective context:
int main() {
int var4[3][5][10][5][4] = { {{{1}}}, {{{2}}}, {{{3}}} };
int (*var1)[5][10][5][4] = &var4[0];
int (*var2)[5][10][5][4] = &var4[1];
int (*var3)[5][10][5][4] = &var4[2];
return 0;
}
less dimensions is better -- this is a very lame suggestion. The question is -- better for what?! As it was suggested in the comments, it all depends on the context. If you need it - you need it. There might not be a better way to express your algorithm.
There are questions of readability and performance. All arrays, no matter on hoe many dimensions, are allocated in memory linearly, so the compiler has to calculate the index. Performance comes from the fact that the compiler needs to do more complicated calculation than with single dimensional arrays. So, if you try to reduce the number of dimensions, you would probably move this calculations from the compiler to your code, most likely loosing performance and readability.
Now, if you, however can split it in independent variables for which you do not need any conditional logic to choose, do it. it will improve both. Do not aggregate unrelated variables into an array, it will reduce both.
I guess in your case, if var1, var2, and var3 are independent, use them this way. If you need a loop to browse them, keep them in an array.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
After learning about c++ through a couple different sources, I found conflicting advice concerning the use of cout/printf(). One source said that printf(), and I quote:
... does not provide type safety, so it is easy to inadvertently tell it to display an integer as if it were a character and vice versa. printf() also does not support classes, and so it is not possible to teach it how to print your class data; you must feed each class member to printf() one by one.
So, the more important thing to me would be the readability factor of using printf(). On the other hand, another source mentioned that cout, with its use of the overloaded operator <<, uses more instructions to execute and can therefore be more expensive in terms of memory over a large program. Although, the person who said this was a systems programmer, in which every bit of performance is vital. But say I wanted to go into game or application development.
Would the performance differences between printf() and cout matter all that much?
In general, does it really matter what I choose to use in an application program?
Thank you for any input.
You would measure the differences on your particular implementation for your specific use case and determine that for yourself.
I would say both lines of reasoning in the question have merit, but you can't generalise about performance.
If you want to go into game or application programming, printf/cout won't be needed too much. The only use in these cases is for debugging.
If you really need to use printf/cout a lot, the difference will be when writing a huge amount of data, otherwise you don't need to bother.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need a temporary string to append and modify pre-existing strings so that i can use with DrawText. That temporary string needs to change inside a function so I have 2 options:
-Use std::string::clear()
-Initialize another temporary string.
I can use and understand both methods but I'm wondering, which one is better?
Edit: To the function in question, having low running-time is essential
Whichever one more clearly reflects the intent of the code is better. The one you would use if you didn't stop to think which was "better" is better.
If (and only if) profiling reveals a performance problem in your function then you might save tiny amounts of time by reusing an existing string.
The memory of the existing string is already allocated. No new memory allocation needs to be made unless the string exceeds the size of the memory allocation.
On the other hand, if you create and destroy a lot of strings, the allocation time can start to add up.
I have some code where std::string allocation and copying dominates the profile. To fix it sometime in the future, we're going to have to implement string pooling, custom allocators and use string_ref instead of string.
So yes, it can be a problem. But measure to find out before trying to fix it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
My application is having memory problems, including copying lots of strings about, using the same strings as keys in lots of hashtables, etc. I'm looking for a base class for my strings that makes this very efficient.
I'm hoping for:
String interning (multiple strings of the same value use the same memory),
copy-on-write (I think this comes for free in nearly all std::string implementations),
something with ropes would be a bonus (for O(1)-ish concatenation).
My platform is g++ on Linux (but that is unlikely to matter).
Do you know of such a library?
copy-on-write (I think this comes for free in nearly all std::string implementations)
I don't believe this is the case any longer. Copy-on-write causes problems when you modify the strings through iterators: in particular, this either causes unwanted results (i.e. no copy, and both strings get modified) or an unnecessary overhead (since the iterators cannot be implemented purely in terms of pointers: they need to perform additional checks when being dereferenced).
Additionally, all modern C++ compilers perform NRVO and eliminate the need for copying return value strings in most cases. Since this has been one of the most common cases for copy-on-write semantics, it has been removed due to the aforementioned downsides.
If most of your strings are immutable, the Boost Flyweight library might suit your needs.
It will do the string interning, but I don't believe it does copy-on-write.
Andrei Alexandrescu's 'Policy Based basic_string implementation' may help.
Take a look at The Better String Library from legendary Paul Hsieh