Timeline for How many strings are created in memory when concatenating strings in Java?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 4, 2013 at 11:36 | comment | added | Marco | @svick Ah, Sorry. Gotcha. :) | |
| Dec 3, 2013 at 20:49 | comment | added | svick | @Marco I'm not questioning that. What I meant is that when you do run into performance problems, solving them often does rely on implementation. So it can be useful to know how does the implementation behave, not just what the spec says. | |
| Dec 3, 2013 at 20:16 | comment | added | Marco | @svick You make decisions related to performance based on.. the actual performance of your code. Actually, in my (albeit limited) experience, the only time you optimize code is when you run into problems with performance after finishing a feature. Only then do you look at the jdk you're working with (sun, ibm, open, etc.) and how you can optimize the code to run on that. Otherwise, maintainability is far more important than performance, because maintainability IS performance. Because maintainability means less bugs and easier changing and adding of features. | |
| Nov 28, 2013 at 21:53 | comment | added | mattnz | "....but that's not enough" - premature optimization and performance anxiety me thinks. As soon as you do stuff not based on the language spec, you open yourself up to being justifiable criticized by the programmer who has to fix your screw up in a few years time. I hate to think how many times I have fixed code that was 'optimized', but unmaintainable and broken according to language spec and worked at the time. So what to do - Understand the language. In this case use the well documented alternates, If you do rely on presumptions and undocumented behavior, test it in the build system. | |
| Nov 28, 2013 at 21:17 | comment | added | svick | @mattnz So how do you propose to make decisions related to performance? Usually, the best you can get from the specification/documentation are big-O complexities, but that's not enough. In any case, performance will always depend on the implementation, so I think it's okay to rely on implementation details when it comes to performance. | |
| Nov 28, 2013 at 21:08 | comment | added | mattnz | @svick: You can gain a great deal by making assumptions, then the compiler is upgraded, an optimization changed etc. The behavior changes causing bugs because you relied on unspecified behavior rather the defined behavior. You know what they say about optimization - a) leave it to experts and b) your not an expert yet. :) If the reliance is performance based only, but still to language specification, then you only loose performance. Many times I have seen code that relied on unspecified or compiler specific behavior break in unexpected ways (mostly C and C++). | |
| Nov 28, 2013 at 20:32 | comment | added | svick | @mattnz It might be interesting to know what the compiler/runtime you're using does, even when it comes to implementation details. This applies especially to performance. | |
| Nov 27, 2013 at 8:00 | comment | added | mattnz | How do you "debate" what a language does, surely you read the specification and know for sure, or its not defined and therefore, there is no correct answer..... | |
| Nov 27, 2013 at 3:07 | comment | added | ahalbert | The people at the interview actually debated over whether or not the literal was, and decided that the literals were created every time. But this makes more sense. | |
| Nov 27, 2013 at 3:05 | vote | accept | ahalbert | ||
| Nov 27, 2013 at 13:23 | |||||
| Nov 27, 2013 at 2:28 | history | answered | 9000 | CC BY-SA 3.0 |