There are two things that bothers me:

1) a performance package can be a nightmare for maintenance, unless
the Kernel development freezes, or unless it's very restricted
  overrides opens a nest of problems, and it's a recipe for creeping
incompatibilities.
  maybe this can be mitigated with duplicated testing (with and
without performance), but still...
  I have maintained my own overrides for years in VW, and it's a never
ending fight.
2) more generally, the code base is an example
  Eliminating all the intermediate objects gives much less expressive
code as Tom underlined
  But providing only naive implementations hides the performance
problems that users will have to learn sooner or later...
  We do not want to optimize prematurely. But we do not want to
completely trade performance either.

I had this very questioning when developing the accelerated large arithmetic.
Maybe not everyone needs it, and it complexifies the base image.
An answer could have been to place hooks in the base image in order to
avoid overrides, so as to make the large arithmetic performance
package unloadable. Such hooks might appear as over-engineered to the
purist, but it's trade offs all the way down ;)
It would have the additional advantage of easing port to other
dialects (Cuis; Pharo, ...).

Ideally, we would write simple code, and the system would make it
efficient for us...
Maybe aggressive inlining could eliminate intermediate object creation
by itself ?

Le lun. 22 févr. 2021 à 11:32, Marcel Taeumel <marcel.taeumel at hpi.de> a écrit :
>
> > Cuis has a PerformanceImprovements package that holds the fast but
> difficult to understand versions of methods that use simpler but slower
> versions in the base image. Maybe that idea could be adopted?
>
> A central package for performance improvements would violate the idea of information hiding and hence impede modularity unless there would be such a package for each specific domain (e.g., CollectionImprovements, KernelImprovements etc.) ... but even then ... if any, extra versions of particular methods should be as close to the original artifact as possible. When programmers would stumble upon a hard-to-understand method in the code browser or debugger, the respective tool should point to the more readable version. And the other way around. I think. :-)
>
> Best,
> Marcel
>
> Am 22.02.2021 11:11:12 schrieb Douglas Brebner <kirtai+st at gmail.com>:
>
> On 20/02/2021 20:51, Levente Uzonyi wrote:
> > My stance on library methods is that they need to be optimized because
> > you don't know how people will use them. If they are fast, people will
> > be happy. If they are not, you'll leave a bad impression.
>
> Cuis has a PerformanceImprovements package that holds the fast but
> difficult to understand versions of methods that use simpler but slower
> versions in the base image. Maybe that idea could be adopted?
>
>
>
>