4 Replies Latest reply on Oct 2, 2006 7:28 AM by adrian.brock

    Code analyze

    alesj

      I went over the code and removed some redundant locale variable definitions, class casts, null initializers, small code optimizations, ...

      I hope that's ok - or are those things intentional for some extra info?

        • 1. Re: Code analyze
          starksm64

          Why bother with such trivial changes, and what is the benefit of it? For all I know hotspot can remove these so I doubt there is any performance issue.

          • 2. Re: Code analyze
            alesj

            Hmm .. you're definitely right, as the hotspot code reducing goes.

            Just asking if anyone is bothered by the change - I'm a minimalistic code person - so I don't want to step on anybody's toes.

            • 3. Re: Code analyze

              Certainly, in most cases, if the JIT can't optimize to a cpu register,
              it will reintroduce the temporary anyway.
              That is true even if you don't use a temporary in your code.

              The optimization to a register (rather than a stack entry)
              will be done regardless of whether the temporary is explicitly declared.

              However, with most modern cpus it makes no real difference
              since the memory (for smallish methods) will be cached on the cpu.
              Making it nearly as fast as registers anyway.

              I'd imagine that hotspot removes unncessary cases if it is JIT compiled?
              If it is not JIT compiled then it doesn't need optimization.

              But the unncessary cast does make the code harder to read.

              • 4. Re: Code analyze

                In general only make these changes if it improves the
                readability/maintainability of the code.

                e.g. removing dead/unnecessary code gives less to maintain
                in future.

                Removing temps doesn't change the semantics of the code
                so it doesn't really change anything.
                In some cases, temps are more optimal.

                e.g. code that doesn't use a temp that should:

                doSomething(getSomethingLotsOfWork());
                doSomethingElse(getSomethingLotsOfWork());
                


                Also temps are useful for tracking down NPEs.
                object.getSomething().getSomethingElse();
                

                should be
                temp = object.getSomething();
                temp.getSomethingElse();
                

                So you know which part was null when you've only got the line number.