9 ms·
"Lessons learned, their strings work" Except that they don't. Either they are 'complete' but massive and thus slow, or they start as 'array of byte' and then t
by roel_v 12y ago
"Lessons learned, their strings work"
Except that they don't. Either they are 'complete' but massive and thus slow, or they start as 'array of byte' and then their designers spend 10 years implementing a more 'complete' string type that is still fast enough and end up as #1 anyway.
Of course the C++ way where there is no string type that everyone uses sucks too, it's just that strings are almost impossible to get 'right' because there is no real 'right' and so many special cases that aren't apparent at first sight.
- kibwen 12y agoI think this bears trumpeting: strings are hard! It's easy to gloss over their issues via garbage collection and pervasive heap allocation, but once you're in a domain where you care about stack allocation and avoiding copies you start running into difficult tradeoffs (above and beyond even the question of string encoding, which is a different beast altogether). Speaking as a dynamic language programmer who's trying to break into systems programming, it took a long time for me to fully appreciate the difficulties around strings. And now that I do, I'm perpetually paranoid about how many allocations my Python programs are doing behind the scenes...
- rwmj 12y agoChrome is a web browser, not a real time operating system.
- ajuc 12y agoIf you care about performance use std::performant_but_tricky_string. 99% of code doesn't care about string-related performance, but needs string anyway.
- crpatino 12y agoIf you care about performance at all, strings are going to slow you down in unexpected and counter-intuitive ways. Far better if you pass around text data as binary buffers (with metadata describing encoding, please), and only convert those to strings once they are ready to be consumed by the user (which is typically not where performance bottlenecks show up anyways)
- ajuc 12y agoIf you care about performance a lot, it may well be that most of your critical paths are in numeric code, and strings are only used to read input and write output. So you should just use strings unless profiling shows problems there.
- Dewie 12y agoI wonder how cavalier people treat strings when they feel like "primitive values" in the language - like Java having the (+) operator for concatenation. I don't agree with the view that "costly" (it's all relative, but anyway) operations should look "costly" (i.e., be a relative eyesore). But I don't doubt that it can affect one's mindset.
- MrBuddyCasino 12y agoIt boggles the mind how many different ways to represent Strings there are in C++, and String handling in general is the major reason I'll never touch it (or C) with a 10 feet pole. I'm interested to hear though how the String handling in Java is broken. This is everything I have to know: - String - CharSequence - char[] / Character[] - StringBuilder Done. Finito. Strings are immutable, the GC will clean up after me. Equality works, Unicode works. Only downside: more memory needed, but nobody except the embedded guys care anymore.
- roel_v 12y agoHehe, ignorance truely is bliss I guess. Just ask yourself: what size is a char in Java? To unearth 90% of the problems with strings in any language, ask two things: first, what size is char? Any secondly, what is the length of a string? If you cannot talk about these things for an hour, you don't really understand how computers deal with strings.
- MrBuddyCasino 12y agoActually, no. 90% of the problems with strings in any language is somebody screwing up the character encoding, usually out of ignorance. The fact that every object in Java has some overhead and probably needs some padding for alignment is utterly irrelevant. But since you asked: - 8 bytes generic object overhead per String - 4 bytes for the char[] ref - 12 bytes for the char[] itself, if non-null, plus probably 4 bytes padding - 12 bytes for length, offset and hash code int fields (3*4 bytes) - and 2 bytes per character stored So I guess 40 bytes for the empty string should be about it. Happy? My customer's servers have usually 8Gb or RAM, 16Gb is becoming the norm. Nobody cares anymore. Maybe its important in your field, I don't know. No mine though. So did I ever need to know this piece of trivia? No. Did I have to fix someone else's code which was relying on the platform default encoding? Lots of times. PP: actually in C, you get the usually security nightmares on top of the encoding stuff.
- Dewie 12y ago> My customer's servers have usually 8Gb or RAM, 16Gb is becoming the norm. Does the cache sizes not matter? Honest question.