IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: But what about the general case?
That's sort of degenerative I think.

The right answer is that the language should enforce that Strings are immutable instead of being wishy washy about it. The very existence of += on String is evil. Were it eliminated, programmers would have to declare mutable string references as StringBuffer (which is a stupid name - MutableString would have been better), which is more efficient.

Interestingly, in ObjectiveC, the opposite is true.

NSString *a = @"Hello";
[a stringByAppendingString: @", world!"];

is more efficient than

NSMutableString *a = [NSMutableString stringWithString:@"Hello"];
[a appendString: @", world!"];

I'm not sure why, but its cheaper to create the new strings in ObjC than it is to use the mutable string.
The average hunter gatherer works 20 hours a week.
The average farmer works 40 hours a week.
The average programmer works 60 hours a week.
What the hell are we thinking?
Collapse Edited by tuberculosis Aug. 21, 2007, 06:19:12 AM EDT
Re: But what about the general case?
That's sort of degenerative I think.

The right answer is that the language should enforce that Strings are immutable instead of being wishy washy about it. The very existence of += on String is evil. Were it eliminated, programmers would have to declare mutable string references as StringBuffer (which is a stupid name - MutableString would have been better), which is more efficient.

Interestingly, in ObjectiveC, the opposite is true.

NSString *a = @"Hello";
[a stringByAppendingString: @", world!"];

is more efficient than

NSMutableString *a = [NSMutableString stringWithString:@"Hello"];
[a appendString: @", world!"];

I'm not sure why, but its cheaper to create the new strings in ObjC than it is to use the mutable string.
The average hunter gatherer works 20 hours a week.
The average farmer works 40 hours a week.
The average programmer works 60 hours a week.
What the hell are we thinking?
New (arguing)
One can argue that Java string handling is just plain bad, even if you do know what they did and why they did it. Better to have ignored the "+" case than to have weirded around it.
"Beware of bugs in the above code; I have only proved it correct, not tried it."
-- Donald Knuth
New I always get dubious...
When someone says there is a single right answer.

Particularly when it is an answer that makes a set of tradeoffs which doesn't fit some common situations.

Immutable strings can have a simpler structure and are faster to access (to allow resizing you need to allow moving the string). However if you are incrementally building up a large string using strings, immutable strings require recopying, and recopying forces you into an n*n algorithm.

Now, you say, just use a StringBuffer (or whatever the current flavour is) object. Well yes. That works. If you try to implement it in code, though, you will eventually hit other bottlenecks as the garbage collector tries to garbage collect on a huge number of little strings. This happens much later, but I have been there, done that. Collecting lots of little objects eventually becomes its own problem. If it is not natively implemented, then it becomes important to do some sort of naive scaling operation. (Having done this in JavaScript I can report that a good heuristic is that when you push a StringBuffer onto a StringBuffer, you resolve the smaller one. Now create one buffer per row, push those onto the ones per table, scalability is now acceptable.)

You know, this is really a headache. I have been there, done that, and don't like it.

Back to the mutable string. OK, it is an immediate significant overhead. Hrm. But go to incrementally build up a string and it bloody works! The first time. The first thing you try. No need to show how good of a programmer you are, how smart you are. You can go off and be smart about something else.

If that initial overhead is acceptable, you don't ever get into having to waste your time worrying about this cr*p. Been there, done that as well. And given current CPU power, I really prefer always wasting some computer time and not having to take out a day or 3 doing performance profiling so I can figure out how to rewrite code that should work the first time.

So I would say that there is no truly "right answer". There are cases where mutable strings make sense. Cases where immutable strings make sense. For me, most of the time, I prefer having mutable strings that work out reasonably well for any access problem, that is good enough. If it isn't good enough some time, then I will make the hard decisions.

Cheers,
Ben
New Don't know why
When I say right answer - I mean right answer to the Java language design decision to have immutable strings that appear to be mutable. Its an efficiency trap. Things that are runtime inefficient shouldn't be easy to write. This is the philosophy behind the C++ STL. You don't implement += on an iterator that has access time O(n). Its deceitful. You would implement += on an iterator that has access time O(1), that makes sense.

I feel the same way about Java's String += operator. If String is immutable, then why did you give me this little thing that appears to modify the string? Again, its deceitful.

(OT - This is one of the things that caused me to pitch C++, its inherent unpredictability. Given the wackiness of operator overloading, I was never entirely sure if a given line of code was expensive or not.)

If your goal is to incrementally build up a big string by continuously modifying some string, then what you want is a string you can modify. Declaring your container a String is bad design choice that appears to be sanctioned by the language designers since they gave you the nifty += and + operators. Its misleading.

I think your other comments had more to do with making the transition from string to text. Text is a much more complicated thing than a string.
The average hunter gatherer works 20 hours a week.
The average farmer works 40 hours a week.
The average programmer works 60 hours a week.
What the hell are we thinking?
Expand Edited by tuberculosis Aug. 21, 2007, 06:26:57 AM EDT
New Whacky overloading. Yes.
"Beware of bugs in the above code; I have only proved it correct, not tried it."
-- Donald Knuth
New That I will agree with
If you give people basic operations, try to make them efficient ones.

That is one thing that Perl has historically done very well on. Everything has a significant overhead. Assume it is about a factor of 10. But their native data types (which there are very few of) can be put together easily to implement virtually any easily stated algorithm. No, you can't choose to make subtle trade-offs. But it is darned easy to get something that works, and if it worse it is probably not, barring your stupidity and that factor of 10, going to be that bad.

While getting everything just right might be really fun, but get it wrong and you are in trouble. If you have that factor of 10 to throw away up front, well I create enough of my own problems to think about. (What do you mean I have deep recursion...?)

Cheers,
Ben
     Java String field optimization tips? - (dlevitt) - (33)
         Strings shouldn't matter. - (admin) - (9)
             JDBC PreparedStatements - (dlevitt) - (8)
                 Depends on the database - (admin)
                 But back to the main question... - (admin) - (6)
                     Yeeha, Scott - (wharris2) - (5)
                         Java profiling usually works pretty well - (admin) - (2)
                             I believe that, no links required - (wharris2)
                             Try: JProbe... -NT - (slugbug)
                         Oh I believe it - (drewk) - (1)
                             Kinda missing the point... - (admin)
         Real world experience - (Yendor) - (18)
             (The technical reason) - (wharris2) - (7)
                 The technical reason behind the technical reason - (admin) - (6)
                     I don't believe it - (ben_tilly) - (5)
                         That would help, but.... - (marlowe) - (1)
                             The scheme addresses those acceptably well - (ben_tilly)
                         Compile time only - (dlevitt) - (2)
                             Are you sure? - (marlowe)
                             Compile time concatenation - (ChrisR)
             Sounds like a shitty compiler. - (tuberculosis) - (9)
                 Wrong, syntactically - (wharris2) - (8)
                     Read it again - (tuberculosis) - (7)
                         But what about the general case? - (ben_tilly) - (6)
                             Re: But what about the general case? - (tuberculosis) - (5)
                                 (arguing) - (wharris2)
                                 I always get dubious... - (ben_tilly) - (3)
                                     Don't know why - (tuberculosis) - (2)
                                         Whacky overloading. Yes. -NT - (wharris2)
                                         That I will agree with - (ben_tilly)
         Depends - (ChrisR)
         I don't think it will affect speed - (Arkadiy) - (1)
             Yep, its a size issue. - (tuberculosis)
         Re: Java String field optimization tips? - (dshellman)

Is you stupid, or is you just high?
62 ms