<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/04/2013 04:15 PM, Filip Pizlo
      wrote:<br>
    </div>
    <blockquote
      cite="mid:AC120B5C-623C-4C74-8274-7C28686272F8@apple.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On Sep 4, 2013, at 3:09 PM, Brendan Eich <<a
            moz-do-not-send="true" href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>>
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div style="font-size: 12px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;">
            <blockquote type="cite">Filip Pizlo <<a
                moz-do-not-send="true" href="mailto:fpizlo@apple.com">mailto:fpizlo@apple.com</a>><br>
              September 4, 2013 12:34 PM<br>
              My point is that having custom properties, or not, doesn't
              change the overhead for the existing typed array spec and
              hence has no effect on small arrays.  The reasons for this
              include:<br>
              <br>
              - Typed arrays already have to be objects, and hence have
              a well-defined behavior on '=='.<br>
              <br>
              - Typed arrays already have to be able to tell you that
              they are in fact typed arrays, since JS doesn't have
              static typing.<br>
              <br>
              - Typed arrays already have prototypes, and those are
              observable regardless of expandability.  A typed array
              from one global object will have a different prototype
              than a typed array from a different global object.  Or am
              I misunderstanding the spec?<br>
              <br>
              - Typed arrays already have to know about their buffer.<br>
              <br>
              - Typed arrays already have to know about their offset
              into the buffer.  Or, more likely, they have to have a
              second pointer that points directly at the base from which
              they are indexed.<br>
              <br>
              - Typed arrays already have to know their length.<br>
              <br>
              You're not proposing changing these aspects of typed
              arrays, right?<br>
            </blockquote>
            <br>
            Of course not, but for very small fixed length arrays whose
            .buffer is never accessed, an implementation might optimize
            harder. </div>
        </blockquote>
        <div dir="auto"><br>
        </div>
        <div dir="auto">As I said, of course you can do this, and one
          way you could "try harder" is to put the buffer pointer in a
          side table.  The side table maps array object pointers to
          their buffers, and you only make an entry in this table if
          .buffer is mentioned.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">But if we believe that this is a sensible thing
          for a VM to do - and of course it is! - then the same thing
          can be done for the custom property storage pointer.</div>
        <br>
        <blockquote type="cite">
          <div style="font-size: 12px; font-style: normal; font-variant:
            normal; font-weight: normal; letter-spacing: normal;
            line-height: normal; orphans: auto; text-align: start;
            text-indent: 0px; text-transform: none; white-space: normal;
            widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
            0px;">It's hard for me to say "no, Filip's analysis shows
            that's never worthwhile, for all time."<br>
            <br>
            <blockquote type="cite">The super short message is this: so
              long as an object obeys object identity on '==' then you
              can have "free if unused, suboptimal if you use them"
              custom properties by using a weak map on the side.  This
              is true of typed arrays and it would be true of any other
              object that does object-style ==.  If you allocate such an
              object and never add a custom property then the weak map
              will never have an entry for it; but if you put custom
              properties in the object then the map will have things in
              it.  But with typed arrays you can do even better as my
              previous message suggests: so long as an object has a
              seldom-touched field and you're willing to eat an extra
              indirection or an extra branch on that field, you can have
              "free if unused, still pretty good if you use them" custom
              properties by displacing that field.  Typed arrays have
              both of these properties right now and so expandability is
              a free lunch.<br>
            </blockquote>
            <br>
            The last sentence makes a "for-all" assertion I don't think
            implementations must be constrained by. </div>
        </blockquote>
        <div><br>
        </div>
        <div>How so?  It is true that some VM implementations will be
          better than others.  But ultimately every VM can implement
          every optimization that every other VM has; in fact my
          impression is that this is exactly what is happening as we
          speak.</div>
        <div><br>
        </div>
        <div>So, it doesn't make much sense to make language design
          decisions because it might make some implementor's life easier
          right now.  If you could argue that something will <i>never</i> be
          efficient if we add feature X, then that might be an
          interesting argument.  But as soon as we identify one sensible
          optimization strategy for making something free, I would tend
          to think that this is sufficient to conclude that the feature
          is free and there is no need to constrain it.  If we don't do
          this then we risk adding cargo-cult performance features that
          rapidly become obsolete.</div>
      </div>
    </blockquote>
    <br>
    This general argument bothers me slightly, because it assumes no
    opportunity cost in making something free(ish). Even if you can
    demonstrate that allowing X can be made fast, it isn't a complete
    argument for allowing X, since disallowing X might enable some other
    optimization or feature or semantic simplification.  Such
    demonstrations are still useful, since they can shoot down
    objections based solely on performance.<br>
    <br>
    But maybe I'm misinterpreting "...sufficient to conclude...that
    there is no need to constrain [the feature]." Perhaps you only meant
    that there is no need to constrain it *for reasons of performance*?
    If so, then you only need consider the opportunity cost of other
    optimizations.<br>
    <br>
  </body>
</html>