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
{{ message }}
This repository has been archived by the owner on Dec 9, 2017. It is now read-only.
It'd be good to be able to separately instrument source files, so that if one file changes, we don't need to re-instrument everything else. The key issue is maintaining unique IIDs for client analyses. There are a couple possible approaches:
change the kind of IIDs generated by the instrumenter to include the current file name. E.g., it could be a concatenated string of the containing file name and the integer IDs we currently generate.
leave the instrumenter as is, but somehow have the replay analysis modify the IIDs passed to client analyses so that they are unique across files.
The tricky thing with option 2 is figuring out what application script is currently executing. I think one could do it by creating an Error object and parsing the stack trace, but it could affect performance (I think we'd need to do it at least at every function entry, to detect when the invoked function is in a different script.) The downside of option 1 is that it could bloat the instrumented code size.
Our best thought so far is a hybrid approach:
Change the instrumenter to invoke some setCurrentFile() callback (name appropriately shortened) at any point that the currently executing JS file may have changed. These points include script entry, function entry, and the top of a catch block (any others?).
Change analysis.js to keep track of the current file based on the above callbacks, and then appropriately combine the current file with the original IID into a new unique IID that gets passed to the client analysis.
Of course, we'll have to change IIDInfo.js to parse multiple sourcemap files, know about the IIDs generated by analysis.js, etc.
Given that the above change would be a moderate amount of work, I will probably put it aside until it's more urgent, unless someone has an idea of a much simpler approach to the problem; suggestions welcome.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It'd be good to be able to separately instrument source files, so that if one file changes, we don't need to re-instrument everything else. The key issue is maintaining unique IIDs for client analyses. There are a couple possible approaches:
The tricky thing with option 2 is figuring out what application script is currently executing. I think one could do it by creating an Error object and parsing the stack trace, but it could affect performance (I think we'd need to do it at least at every function entry, to detect when the invoked function is in a different script.) The downside of option 1 is that it could bloat the instrumented code size.
Our best thought so far is a hybrid approach:
setCurrentFile()
callback (name appropriately shortened) at any point that the currently executing JS file may have changed. These points include script entry, function entry, and the top of a catch block (any others?).analysis.js
to keep track of the current file based on the above callbacks, and then appropriately combine the current file with the original IID into a new unique IID that gets passed to the client analysis.Of course, we'll have to change
IIDInfo.js
to parse multiple sourcemap files, know about the IIDs generated byanalysis.js
, etc.Given that the above change would be a moderate amount of work, I will probably put it aside until it's more urgent, unless someone has an idea of a much simpler approach to the problem; suggestions welcome.
The text was updated successfully, but these errors were encountered: