Skip to content
This repository has been archived by the owner on Dec 9, 2017. It is now read-only.

Separate instrumentation of source files #10

Open
msridhar opened this issue Nov 26, 2013 · 0 comments
Open

Separate instrumentation of source files #10

msridhar opened this issue Nov 26, 2013 · 0 comments

Comments

@msridhar
Copy link
Contributor

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:

  1. 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.
  2. 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:

  1. 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?).
  2. 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant