On 21 June 2011 18:19, Kirk <[email protected]> wrote: > errr, profilers don't find write bandwidth bottlenecks in large > applications. There is a *lot* more to profiling then just blindly throwing > an execution profiler at an application. >
What profilers *can* do is identify performance hotspots, areas in the program where you can then take the informed decision to e.g. drop immutability in a controlled fashion, while keeping it (and all the associated benefits) throughout the rest of the system. If a function can be substituted with a constant return it wasn't much of a > function was it.. and again, having an object take responsibility for it's > internal state takes care of a lot of problems. Just look at actors. > It's the very definition of a function, as used by mathematicians. If sin(2π) were to *ever* yield a non-zero value, or cause the computer to go "ping!", then I think we'd all be rather surprised and concerned. Yet I'd be somewhat uncomfortable with the idea that "sin" isn't much of a function, it's an old friend and something that I've used extensively. Having said that... Yes, actors are also a nice approach, and we ultimately have to deal with side-effects at some point if our programs are intended to do more than simply warm the CPU. Regards, > Kirk > > > On Jun 21, 2011, at 10:27 AM, Kevin Wright wrote: > > > > On 21 June 2011 03:40, Steve Lindsay <[email protected]> wrote: > >> On Jun 21, 3:01 am, Kirk <[email protected]> wrote: >> > >> > Again, I'm not against immutability, it just seems that we've all picked >> up on that sound bite and have forgotten all of the other colors that make >> the world interesting. >> > >> >> Hasn't most of the immutability push (outside of this thread at least) >> been about safety, maintainability, ability to reason about complexity >> etc., rather than performance? >> >> > Oh absolutely. It's very refreshing being able to see some value declared > at the top of a class and being certain that it's exactly the same thing > further down the file. This becomes even more useful if you want to be > certain that some other thread also hasn't fiddled with it. > > It's also much easier dealing with pure functions, guaranteed to always do > the same thing for the same input and not have side effects. Referential > integrity means that you can substitute a function call with its > precalculated result; this particular optimisation is almost as old as > programming itself, with one classic example being a lookup table of > trigometric functions. > > So dropping immutability is a very useful optimisation, but it certainly > isn't the only one in our toolbox, and there are other optimisations that > immutability makes possible. As always, we're better off starting with > clean and provably correct code, then letting a profiler be our guide as to > where speedups can be found. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
