You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Shiny 1.10, launching many promises at once e.g. by mirai::mirai() or mirai::mirai_map() is now noticeably slower than in previous versions.
Using this mirai Shiny vignette example, this blocked 1-2s before the counter started to update in v1.9.1, whereas in v1.10 it's taking up to 14s.
Cause
The cause has been isolated to this PR #4156 related to limiting deep call stack growth.
Profiling using profvis shows recursive calls to the hashing for stack trace deduplication taking up the most of the time. In fact most of the time is spent in this getCallNames() function, with the format() call within that being a particularly egregious offender.
Solution
@cpsievert looked over the evidence I provided and agrees on the cause. He also suggested a fix that gets us most of the way back (now blocking 3-4s).
As hashing uses rlang::hash(), this can take any arbitrary R object not just a string. Hence we can use another version of getCallNames() that completely avoids the expensive formatting calls, as long as they keep the structure of the calls and produce unique hashes.
@jcheng5 this is the issue I mentioned in passing a while ago.
The text was updated successfully, but these errors were encountered:
Symptom
In Shiny 1.10, launching many promises at once e.g. by
mirai::mirai()
ormirai::mirai_map()
is now noticeably slower than in previous versions.Using this mirai Shiny vignette example, this blocked 1-2s before the counter started to update in v1.9.1, whereas in v1.10 it's taking up to 14s.
Cause
The cause has been isolated to this PR #4156 related to limiting deep call stack growth.
Profiling using profvis shows recursive calls to the hashing for stack trace deduplication taking up the most of the time. In fact most of the time is spent in this getCallNames() function, with the
format()
call within that being a particularly egregious offender.Solution
@cpsievert looked over the evidence I provided and agrees on the cause. He also suggested a fix that gets us most of the way back (now blocking 3-4s).
As hashing uses
rlang::hash()
, this can take any arbitrary R object not just a string. Hence we can use another version ofgetCallNames()
that completely avoids the expensive formatting calls, as long as they keep the structure of the calls and produce unique hashes.@jcheng5 this is the issue I mentioned in passing a while ago.
The text was updated successfully, but these errors were encountered: