Perhaps it's sufficient to measure the uptime and estimate the machine's 
performance based on that value. On slower machines it should take longer 
to get to the same point in the startup process.

By uptime I mean what's shown in the VM stats:

| vmStartTime uptime |
vmStartTime := Smalltalk vmParameterAt: 20.
uptime := vmStartTime ~= 0 "utcMicrosecondClock at startup in later Spur VMs"
 	ifTrue: [Time utcMicrosecondClock - vmStartTime + 500 // 1000]
 	ifFalse: [Time eventMillisecondClock].

which may be simplified to:

| uptime |
uptime := Time utcMicrosecondClock - (Smalltalk vmParameterAt: 20) + 500 // 1000.


Levente

On Sat, 2 Jan 2021, Eliot Miranda wrote:

>
>
>> On Jan 1, 2021, at 9:43 PM, tim Rowledge <tim at rowledge.org> wrote:
>> 
>> On a Pi 4 - 
>>> 
>>> (Time millisecondsToRun:[ 25 benchFib ]) > 200
>>>      or: [ (Time millisecondsToRun: [ 64 benchmark ]) > 200 ]
>> 
>> 19mS & 143mS
>> 
>> I don't see an issue with possibly slowing down the first startup to test performance as long as
>> a) it isn't a multi-second delay
>> b) it says what it is doing
>>   "Checking system performance in order to provide advice on suitable setup options"
>> would be apropos.
>
> I’m sorry but it’s completely unacceptable.  19ms is an age.  Simple Unix commands are done in that time.  50 of those and a second has elapsed.  Imagine one is using a Smalltalk script with the Unix find command and one can not do better than 50 applications per second.
>
> We know that we can derive a meaningful performance figure from existing work.  Why are we even considering adding unnecessary overhead?
>
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- Not all his dogs are barking.
>> 
>> 
>>