Recently Etienne wrote of the intent to speed up extendTraces, and I replied with a description of related techniques used in the VPython project that may for all I know be well known. Yesterday I came up with another technique, maybe less well known, that could usefully be incorporated in a more efficient extendTraces.
The situation is one where intensive computations are coupled with incremental graphing of results of those on-going computations. Both the JavaScript computations and the graphing are of course run off setTimeout(), and the challenge is to use as big a fraction of the second as possible for both activities.
Just before executing extendTraces I set lock = true, and when there arrives a callback from extendTraces that Plotly has finished, I set lock = false. While Plotly does its work (apparently with many calls to setTimeout), computations also run when they can, generating additional graphing data which however cannot be sent immediately to Plotly. So during the time that lock is true, data to be sent to Plotly is pushed to a list, waiting for the lock to become false, at which time extendTraces is driven again from the accumulated data (and the list of pending output is cleared).
My suggestion is that in a revision of extendTraces it would be very helpful to the Plotly user to have this lock machinery embedded in Plotly itself. In other words, extendTraces would be callable at any time but would actually trigger graphing (and clear the task list) when ongoing Plotly updates were complete. This would free up the Plotly-using program from having to implement this lock machinery itself.
Bruce