Yes!
But, you need a recent version of OS X and Safari. See the README on the project page for details on downloading and running a Timelapse nightly binary.
In theory, no. In practice, usually not.
Because Timelapse records inputs to a program instead of the actual instructions executed, relatively little time is spent capturing and saving data during recording. Overhead should scale with the amount of user input, not CPU time. For applications with high rates of user input (such as video games), Timelapse doesn't introduce a noticeable framerate drop.
Due to prototype implementation shortcuts, network-bound applications do experience some slowdown. For example: the resource cache is disabled, so everything must be re-downloaded from the network. Another example is that HTTP pipelining has been disabled to sidestep nondeterminism in the network scheduler.
On program replay, Timelapse can replay the execution much faster than the speed at which it was recorded. This is due to zero network traffic on replay, immediate timer callbacks, and that the results of some platform functions can be memoized instead of re-executed.
All HTTP requests and responses are captured, so the recording's size is the sum of all resources requested during the execution, plus the size of each nondeterministic input. Most such inputs are really small and highly compressible. The total size of the recording will scale with the number of program inputs, such as network requests, user mouse/key input, and timer callbacks.
In our preliminary performance evaluation, applications with high rates of user input (such as timer-based video games) generate at most 250KB/minute of input, and this can be compressed to under 50KB for storing or transmitting recordings. These numbers do not include network traffic/page resources, which can also be compressed.
On replay, network requests are intercepted by an in-browser network simulator.
External servers will not re-receive network requests during replay. A network-level record/replay simulator captures all HTTP headers and traffic when recording, and only allows the same requests to occur on replay. From the web page's point of view, the external server appears to behave the same on recording and replay, though on replay the network traffic actually originates from the recording..
Right now, no.
Timelapse is first and foremost a research prototype, and multi-platform support has not been a priority. For the initial prototype, We have stuck with the Mac platform and Safari embedding application for reasons of expediency. Other platforms will definitely not work out of the box. That said, the implementation approach for Timelapse is platform-independent and does not overly rely on platform-specific APIs. See the next question for details.
Enough to give pause, but it's finite.
There are several platform-specific parts of code to implement, in order of increasing effort:
Each platform has its own build system and/or build settings. In general, Timelapse has only maintained build settings for the Mac port. Timelapse's files and build configurations need to be added to each port's build system. This is mainly a trial-and-error task to see what files are missing.
Each embedding application/library uses a different subset of the WebKit/WebKit2 embedding APIs. In some cases, embedders may use API calls that have not yet been piped through Timelapse's page input proxy. Fixing this could be as simple as calling a different method, or as hard as adding/controlling an entirely new source of nondeterminism.
Each platform introduces its own sources of nondeterminism, which must be controlled for record/replay to work correctly. For example, the Timelapse code specific to the Mac port exists to clear the system resource cache, network cache, and memoize accesses to the system-shared cookie jar.
The infrastructure for recording and replaying is a part of the WebKit engine, which is mostly written in C++. The developer tool UI is written using HTML, CSS, and JavaScript. Accompanying scripts and tools are predominantly written in Bash and JavaScript.
In principle, it's simple to write a regression test that starts up a test page, records some interaction with it, and compares replay output to record output. WebKit's test harness provides access to test both the Web Inspector UI, and the C++ backend to which it communicates.
For now, few such tests are written for Timelapse. At this point, bugs are still easy to witness on small test pages, so an automatic test suite is not (yet) necessary. The UI changes frequently, so writing UI tests at this stage is premature. Were Timelapse to be included with WebKit, tests would definitely be necessary to build confidence in the implementation and prevent regressions.
This is less clear than the above question about platforms. Chrome
uses a different JavaScript engine, so certain parts of the
Timelapse replay engine would need to be reimplemented or
refactored. In particular, capture/replay of
the Date.now and Math.random may require
V8 support. There may also be some issues arising from the fact that
Safari and Chrome use slightly different versions of Web Inspector.
It seems very unlikely.
Timelapse's architecture is suited to large and monolithic applications. The current record/replay design is unsuitable for Firefox, because Firefox has a fundamentally extensible, component-based architecture. This environment is more akin to record/replay work in the distributed systems community. So, record/replay may be possible, but it would be novel research and not a straightforward reimplementation.
If you would like to contribute features or patches to the project, the easiest way is to create a fork on Bitbucket and send a pull request. Drive-by bug fixes and incremental features are very welcome, but larger contributions should occur with some level of coordination.
Computer Science and Engineering at the University of Washington.
© 2011–2012 Brian Burg and the University of Washington. All Rights Reserved.
The contents of this website, unless otherwise noted, are available
under the
Creative Commons
Attribution-ShareAlike 3.0 Unported License.