Implicit sharing vs. c++ refereces

[karagog]

Code overhead ? You can write code that manages implicit shared data once, and then reuse it for most of your containers.

I don't mean you have to write code twice, I am talking about the space that this code occupies in the final executable. An executable that contains an implicitly shared QString is larger than one that contains a non-implicitly shared QString (intuitively this makes sense, because the implicitly shared QString has a more complex algorithm to manage the data).

What do you mean with memory overhead, a pointer to data and integer counter ?

Yes, admittedly it's a small overhead; almost not worth caring about. But my String class is only 12 bytes split between the stack and heap (pointer to begin, pointer to end, memory of the total capacity), and a QString must be at least 16 bytes (12 bytes for the pointer, length and capacity values, plus 4 bytes attached to the pointer for the reference counter. Does anyone have the actual size of a QString handy?) That's at least 33% larger than my class. Yeah, yeah, I know BFD it's a difference of 4 bytes! Plus at runtime with actual data in the container, the size of the container eclipses the size of the memory overhead. Like I said, almost not worth mentioning.

I failed to see a big runtime overhead either.

Runtime overhead is probably the biggest issue (although again it may be negligible for most applications). Incrementing and decrementing the reference counters upon construction, destruction or assignment is hardly an issue because it happens so seldom compared to all the other operations you carry out on a String. But you also have to count up every time you need check the reference counter, which is actually every time you change the data (need to check if there's another reference to the data somewhere, so it can detach). If you have a loop that iteratively assigns values to individual string elements, then this must check on each and every assignment that there is not another reference somewhere else. This is a runtime overhead that I don't deal with in my non-implicitly shared string class.

I guess more people will enjoy your code if its easy to use

They'll enjoy it also if it's faster and has a smaller code/memory footprint

I don't think there's an obvious "best" approach; I think it depends highly on the experience and skill of the developer and on the performance requirements of the application. It's nice to have implicitly shared objects if that makes coding easier for you, but if performance is critical I contend that c++ references are the way to go. And personally I find references easier to understand and follow, especially because with implicitly shared classes you have to think a lot harder about when the copy will actually happen (if you care when it happens).

[stampede]

I think overhead that comes with incrementing and decrementing reference counter is nothing if compared to wrong algorithm used to process the regular or implicit shared strings. I bet that in most apps incrementing one integer or checking the pointer to shared data is something that you probably won't even notice in profiler output.
I buy you a beer (if you like it, ofc ) if you can show me just one real-world app (that's the only thing our customers will care about:P) where using implicit shared container classes killed the performance, or created a significant overhead.
Anyway I got your point, and I agree that there is nothing like the best solution - good luck with your implementation, maybe you can share it someday.

[karagog]

I buy you a beer (...) if you can show me just one real-world app (...) where using implicit shared container classes killed the performance, or created a significant overhead

I'll take the beer if it's gluten free Unfortunately, that's no joke, but gluten intolerance is not a topic on this forum

I would accept your challenge, except it's next to impossible to show this. If you had a QString implementation that didn't use implicit sharing then I could compare it to the regular QString, but comparing my implementation to QString is like comparing apples and oranges. QStrings use UTF-16 encoding internally and I use UTF-8 encoding, which is just one of many potential differences in performance.

Apart from the aforementioned differences, the test program I would use is as follows: It would be a web server that has lots of large strings and also implicitly-shared copies of those strings. Then a request comes in from the web and the server modifies only the first character of each of the implicitly-shared copies. This makes it so the overhead of deep-copying all the strings happens at the time of the web request, so the response is delayed to the consumer. Yes, this is a terribly naiive implementation, but if you didn't know much about implicit sharing you might make this mistake. It would be better and clearer if the server made deep copies up front so they don't waste time while serving a request, which is very clear using regular non-implicitly shared classes.

The way I see it, Qt made a design choice to use Implicit sharing on practically all of their classes, assuming that this would be the best for MOST applications and MOST developers. Perhaps they are right in this assessment. I however made my own design choice against Implicit sharing (after lots and lots of deliberation) because I just didn't see enough benefit to justify the extra work. And since nobody is paying me (hobby code only...) I get to make all the important decisions

good luck with your implementation, maybe you can share it someday

Thanks, that's the idea. Eventually when my library matures a bit I will release it with an open-source license. An early version of it can already be found in a couple open-source applications I wrote on Sourceforge.net GPasswordMan (soon to be renamed Gryptonite) is the one I am most fond of.