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...