1. 19
  1.  

  2. 8

    I frowned when I saw that one character difference. I’m glad that’s now fixed. It’s really annoying when a standard library gives you a foot gun like that.

    1. 4

      Agreed. Rust’s stdlib containers do not allocate by default. This makes a lot more sense to me.

      1. 2

        Assuming “Java 1.3” meant JSE1.3, it was released in 2000. I’m not sure if initializing a HashMap in that way is really a footgun. We don’t know the context. It’s possible it was used in the application in a non-expected way, by someone who was not familiar with Java.

      2. 7

        Saw this comment on HN

        Good lord, this long-winded writing style is maddening to read! Here’s what he changed:

        Set aSet = new HashSet();

        to:

        Set aSet = new HashSet(0);

        His explanation:

        “Most of these sets were empty for the entirety of their life, but each one was consuming enough memory to hold the default number of entries. Huge numbers of these empty sets were created and together they consumed over half a gigabyte of memory. Over a third of our available heap.”

        I’m not sure he ever got around to explaining how it saved “half a million dollars”, though.

        1. 5

          Do you agree with this quoted comment, or are you critical of it?

          Because to me it’s the worst of HN - an attempt at a TL;DR that’s simultaneously wrong and snarky.

          There’s no mention of the discussion about how and when to optimize, no mention of the circumstances of the fix (old legacy code written in old Java), and it implies that anything longer than a tweet is not worth anyone’s time.

          I was going to ask for a link to the quote but now I’m glad to let the author of this comment languish in obscurity.

          1. 5

            I kind of agree with the meat of the comment, though the tone seems a bit harsh. It’d be nice IMO to start with the change itself, then go onto why it was a huge boost, and then go into the discussion on how and when to optimize etc.

            1. 3

              My bad, I should have given some more context

              Link to the original comment:

              https://news.ycombinator.com/item?id=21937783

              I commented it here because I found it pretty odd. As a non-developer guy who is pretty into tech, I think that HN community (also /r/programming on reddit) people are too critic towards other community members

              1. 2

                Thanks for clarifying, and I’m not going to interact with that comment on HN ;)

                I do hope that the discussion here is held to a higher standard. I enjoyed the linked post, and found it insightful.

          2. 5

            valueOf will return one of two fixed Boolean instances while calling the constructor will always allocate a new object.

            Also, new Boolean(false) will wreak utter havoc if you ever use == (identity comparison) on boxed booleans by accident, rather than .equals(). It’s especially bad in Clojure, where new Boolean(false) will behave as true but print as false.

            1. 3

              I wonder if there’s value in leaving breadcrumbs for those who follow to solve problems like this.

              I know of a lot of places in code I’ve written, or read, where it’s clear that there was low hanging fruit waiting to be picked if the time was ever right, but it was rarely marked. How much time and money do we lose in trying to uncover what was known and lost?

              I might start leaving // OPTI: comments in code if I think something is worth investigating later, should the need arise.

              1. 1

                I try to do this where I can with ‘TODO’ comments explaining what I/others would want to do at some point in the future wrt optimizations or other similar changes..

                1. 1

                  and do you ever get to fix them?

                  1. 3

                    I’m working on a game in my spare time. There’s a couple of places I know I can probably get a significant speed-up, but doing that work will take time which is better spent developing mechanics.

                    As a result of leaving those TODO comments, I know exactly where I should look if performance ever becomes an issue. Or, if performance of a particular piece of code never becomes an issue, I won’t have wasted my time optimizing it, yet having those comments about how the code might scale worse than it could have is still valuable.

                    I do like the idea of using // OPTI: instead of // TODO: for these cases though, exactly in order to differentiate between stuff which should be done in the future (“TODO”) and intentionally missed optimization opportunities (“OPTI”).

                    1. 2

                      Yeah, my text editor of choice (vim) will highlight the TODO lines so they are obvious, which helps. I’ve addressed some since adding them, sometimes grepping for TODO and picking one to do is a nice break from the norm.

                      1. 3

                        It is nice to do todos, indeed. But most TODOs I see in production code are from programmers long gone, which will never get done.

                      2. 1

                        I’m not craftyguy, but yes, a few months ago. I had opportunity to profile code I wrote to improve the speed. For the background, it’s written in Lua [1] and I intended for it to be a “proof-of-concept” but of course it was put into production without my knowledge [2]. We were able to go several years before I profiled the code. One area was expected, another area not so expected. I got about a 25% boost in speed, not too bad for the small amount of code that actually changed.

                        [1] It parses SIP messages, and I use LPEG to do the parsing.

                        [2] That happened about four years ago.