Le 18/12/2024 à 13:16, Tomas Kalibera a écrit :
On 12/18/24 01:19, Simon Urbanek wrote:
It seems benign, but has implications since checking time is actually
not a cheap operation: adding jus ta time check alone incurs a penalty
of ca. 700% compared with the time it takes to call
R_CheckUserI
On 12/18/24 01:19, Simon Urbanek wrote:
It seems benign, but has implications since checking time is actually not a
cheap operation: adding jus ta time check alone incurs a penalty of ca. 700%
compared with the time it takes to call R_CheckUserInterrupt(). Generally, it
makes no sense to che
> Simon Urbanek
> on Wed, 18 Dec 2024 13:19:04 +1300 writes:
> It seems benign, but has implications since checking time
> is actually not a cheap operation: adding jus ta time
> check alone incurs a penalty of ca. 700% compared with the
> time it takes to call R_Check
It seems benign, but has implications since checking time is actually not a
cheap operation: adding jus ta time check alone incurs a penalty of ca. 700%
compared with the time it takes to call R_CheckUserInterrupt(). Generally, it
makes no sense to check interrupts at every iteration - you'll fi
This seems like a great idea. Would it help to escalate this to a
post on R-bugzilla, so it is less likely to fall through the cracks?
On 12/17/24 09:51, Jeroen Ooms wrote:
A more generic solution would be for R to throttle calls to
R_CheckUserInterrupt(), because it makes no sense to check 1
A more generic solution would be for R to throttle calls to
R_CheckUserInterrupt(), because it makes no sense to check 1000 times
per second if a user has interrupted, but it is difficult for the
caller to know when R_CheckUserInterrupt() has been last called, or do
it regularly without over-doing
tl;dr: R_CheckUserInterrupt() can be a performance bottleneck
within GUIs. This also affects functions in the 'stats'
package, which could be improved by changing the position
of calls to R_CheckUserInterrupt().
Dear all,
Recently I was puzzled because some code in a packag
