Hi, Thanks for bringing up this issue.
> > One option (very, very painful, and even slower) would be a proper > device simulator which simulates both the CPU and the system hardware > (of *some* B2G phone). This would produce the most realistic result > with an emulator. That is what the emulator is already doing. If we start emulating HW down to individual CPU cycles, it'll only get slower. :( > Another option (likely not simple) would be to find a way to "slow down > time" for the emulator, such as intercepting system calls and increasing > any time constants (multiplying timer values, timeout values to socket > calls, etc, etc). This may not be simple. For devices (audio, etc), > frequencies may need modifying or other adjustments made. If we do that, writing and debugging tests will take even longer. > We could require that the emulator needs X Bogomips to run, or to run a > specific test suite. > > We could segment out tests that require higher performance and run them > on faster VMs/etc. Do we already know which tests are slow and why? Maybe there are ways to optimize the emulator. For example, if we execute lots of driver code within the guest, maybe we can move some of that into the emulator's binary, where it runs on the native machine. > > We could turn off certain tests on tbpl and run them on separate > dedicated test machines (a bit similar to PGO). There are downsides to > this of course. > > Lastly, we could put in a bank of HW running B2G to run the tests like > the Android test boards/phones. There are tests that instruct the emulator to trigger certain HW events. We can't run them on actual phones. To me, the idea of switching to a x86-based emulator seems to be the most promising solution. What would be necessary? Best regards Thomas > > > So, what do we do? Because if we do nothing, it will only get worse. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
