3 ms·

For me it runs at full speed in both stable and developer versions of Firefox (but even then, audio is bad at times). But still, I looked at performance out of

For me it runs at full speed in both stable and developer versions of Firefox (but even then, audio is bad at times). But still, I looked at performance out of curiosity. After running it under FF's profiler for a moment, it looks like a sync executed after every opcode recalculates the framebuffer (`step_until_next_audio_buffer -> cpu::microops::read_byte_from_memory -> emulator::sync -> gpu::scanline::write_scanlines`) and uploads it to the canvas with `putImageData`, which takes ~35% of execution time. Sounds like that could be redundant work, since I'm pretty sure the canvas isn't actually redrawn until the wasm execution yields back to the browser. EDIT: also, the emulator can't really be ran in debug mode, since 1. it blows the wasm stack (presumably when creating the huge `Emulator` struct, a not uncommon issue in Rust; I had to hack in bigger stack size with linker args), and 2. is panics on int overflows `apu::step`.

catapart 2y ago
Yeah, still being on Windows 10, I almost didn't put the complaint in the comment. Lots of reasons it might just be an environment issue for me. But, in my development experience with firefox, the issues it seems to have always seem performance related (or compliance with web standards related), and I figured that even if others weren't seeing the issue, there was still probably something underlying that could be figured out. So thanks for going through the debug! It's nice to know that there may be an optimization available for the project, and it feels like it might even be an additional performance gain for chromium, if I'm understanding you right? Might be some reason they need to do that sync after every opcode, but I agree with your suspicion that the canvas is probably being over-rendered to.
- adrian17 2y ago
  FWIW, the thing I've found as the slowest single factor on my machine, might not be the slowest on yours; I might have not noticed the real cause of slowdowns on your machine at all, and you may be the only one able to diagnose it. (and for the record, I'm on W10 too.) Also, my personal experience from optimizing https://ruffle.rs/ https://ruffle.rs/ is that in many cases Firefox's wasm runtime can behave slightly faster than on Chrome for some reason; and performance issues are often instead caused by other APIs like the canvas.

catapart 2y ago

Yeah, still being on Windows 10, I almost didn't put the complaint in the comment. Lots of reasons it might just be an environment issue for me. But, in my development experience with firefox, the issues it seems to have always seem performance related (or compliance with web standards related), and I figured that even if others weren't seeing the issue, there was still probably something underlying that could be figured out. So thanks for going through the debug! It's nice to know that there may be an optimization available for the project, and it feels like it might even be an additional performance gain for chromium, if I'm understanding you right? Might be some reason they need to do that sync after every opcode, but I agree with your suspicion that the canvas is probably being over-rendered to.

adrian17 2y ago
FWIW, the thing I've found as the slowest single factor on my machine, might not be the slowest on yours; I might have not noticed the real cause of slowdowns on your machine at all, and you may be the only one able to diagnose it. (and for the record, I'm on W10 too.) Also, my personal experience from optimizing https://ruffle.rs/ https://ruffle.rs/ is that in many cases Firefox's wasm runtime can behave slightly faster than on Chrome for some reason; and performance issues are often instead caused by other APIs like the canvas.