Hi Levente,


> meant.  My own criteria is "methods which are called thousands of times
>> per minute" _today_.
>>
>

> A rule of thumb could be that if a core method (e.g. anything in
> Kernel/Collections) is part of an API and it's not there to support a very
> specific task (e.g. Dictionary >> #associationDeclareAt:), then its
> performance should be taken into account.
>

That sounds like it only exempts utility methods ("specific tasks").
Technically, this should leave me afraid that you might want to inline
Dictionary>>#at:, but I'm relatively sure you don't.  #at: is the most
basic featured accessing method for understanding and using a Dictionary,
so I hope you agree that's one that should retain its exemplar status.

OTOH, #associationDeclareAt: and #isOctetString, by their nature, are only
of interest to developers.  Users would never use those methods, so
optimizing them would be fine I suppose.  Methods which take block
arguments also tend to be not as usable by users, since passing a block
requries writing some code.  So it seems we have _some_ concrete criteria
starting to form simply by having looked at a few examples:

   - methods which run hundreds of times per minute
   - methods which take block as arguments
   - methods which are concerned with internals instead of externals

#isAsciiString seems like it could go either way, so I'm fine if you and
Eliot prefer it to be optimized.  For me this discussion itself to get a
slightly better understanding of each others' positions with the request to
keep Dynabook users in mind when evaluating future such optimizations, is
more important.

Regards,
  Chris

On Fri, May 4, 2018 at 2:43 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:

> On Thu, 3 May 2018, Chris Muller wrote:
>
>                   On a serious note, libary methods, like that method,
>> ought to be fast,
>>
>>
>>             Every method in the image is a library method, so what do you
>> mean by
>>
>>
>>       Really? Explain me how Browser >> #defaultBrowserTitle, a method I
>> chose randomly, is a library method?
>>
>>
>> Well, I was actually asking for clarification from _you_  for the meaning
>> of "library method", since you were the one assigning an "ought" to them
>> :).  So I started out with it meaning, "every method in the base image", as
>> a means to open up the question of what you
>> meant.  My own criteria is "methods which are called thousands of times
>> per minute" _today_.  But as the guy whose done more of these sorts of
>> method optimizations than anyone (most of which I love), I am actually
>> *truly curious* about YOUR criteria on this.  What
>> methods in the image would Levente prefer to be more readable than
>> performant, and why?
>>
>
> I can't give you an exact definition of a "library method", but I'm sure
> that String >> #isAsciiString is one, while Browser >> #defaultBrowserTitle
> is not.
> A rule of thumb could be that if a core method (e.g. anything in
> Kernel/Collections) is part of an API and it's not there to support a very
> specific task (e.g. Dictionary >> #associationDeclareAt:), then its
> performance should be taken into account.
>
> Btw, please have a look at String >> #isOctetString.
>
> Levente
>
>
>
>>
>>
>> > ....
>>
>>
>>
>>                   because you can't know in what situation they will be
>> used. Saying that it's
>>                   not even used is therefore not a valid reason.
>>
>>
>>             That's only true for the very lowest-level methods.
>> Generally, it's
>>             better to design and code for what's known, and NOT try to
>> code for
>>             the future / unknown.  IF and when that future comes, it'd be
>> easy
>>             enough for you to deal with any performance issues at THAT
>> time.  In
>>             the meantime, we "ought"  :) to keep as much beautiful minimal
>>             elegance as we can.
>>
>>
>>       So, if I decided to write a mail transfer agent, and I found that
>> optimizing #isAsciiString would bump the throughput by, let's say, 10%,
>> then and only then would I be allowed to change the implementation in
>> Squeak? Or should I keep my optimized version in
>>       my image, because it's not considered generally useful?
>>
>>
>> Yes.  That's when you'll have the concrete context necessary to enable
>> you to make the best implementation choice.  Until then, degrading code
>> readability in exchange for no real-world performance benefit just... well,
>> degrades the code...
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180507/854bdf49/attachment.html>