Thanks, the emulator is open source and it's at https://github.com/tdondich/vue-2a03-emu .
So here's the thing. When I run chrome profiler, it at least says the majority of time is in that tick. And well, no matter how hard I try on chrome, I can't get the emulator running past 14 frames per second. HOWEVER, the same codebase on Firefox is blazing fast, exactly the speed it should be. So I'm going around in circles trying to figure out what v8 is doing differently that firefox's SpiderMonkey just appears to do faster. Chrome's profiler shows the majority self time in this tick method, so I don't understand what could be causing it in there. The only other thing that I can think of that is not javascript code related is rendering related which renders pixels to a canvas. But I would be shocked if that's an issue for chrome. Is there something I might be thinking erroneously on this? How else can I go about figuring out why chrome's performing less than half the speed of firefox when executing the same emulator code? Thanks for your response! On Tuesday, September 25, 2018 at 10:14:59 PM UTC-7, Caitlin Potter wrote: > > Oop, re-reading that, I realize that was unclear --- The compiler deopts > because operations in those rare branches haven't been run yet, so there is > no type feedback and the compiler doesn't know what to do with them. So, v8 > deopts, and resumes execution from the slow path, which collects that > information --- so that next time the function is evaluated, that same > deopt won't happen (but, you have a number of branches like that, so there > are many opportunities for this to happen). But that's sort of the nature > of this kind of state machine, so I'm not sure you can do much about it. > > > On Sep 26, 2018, at 1:11 AM, [email protected] <javascript:> wrote: > > > > Sounds like a cool project :) > > > > So, I think these deopts are all expected, and I don't think you're in a > deopt loop (but I could be wrong about that). Basically what's happening > is, your `tick()` function is called frequently, you increment counters > (dot count, scanline count, instruction cycle count, etc), and there are a > number of branches in your functions which depend on those variables --- so > they aren't reached every time. Because of that, the compiler decides to > deopt when it sees them, so that the slow case can run them and collect > information that the optimizer can make use of next time to speed them up. > > > > Is the 30% measure of performance only measuring time spent in the > tick's frame, or does it also include functions invoked by tick()? > > > >> On Sep 25, 2018, at 11:24 PM, Taylor Dondich <[email protected] > <javascript:>> wrote: > >> > >> I'm building a NES emulator in Javascript and there's a certain > function of code that when gathering performance metrics in google chrome, > shows that the self time for this method is over 30% of overall execution > time. That's pretty excessive to what looks like a tree of if/else > statements. I was wondering if anyone can look at it to see if there's > something to this structure that would have the v8 engine choke on it. > I've also gathered a collection of v8's opt and deopt messages regarding > this method and so far I'm having a very hard time finding documentation > online to understand the deopt reasons and how to potentially code to > safeguard against the constant deopts. > >> > >> I've attached the code in the method as well as the opt/deopt log. > Would love any feedback! > >> > >> > >> > >> -- > >> -- > >> v8-users mailing list > >> [email protected] <javascript:> > >> http://groups.google.com/group/v8-users > >> --- > >> You received this message because you are subscribed to the Google > Groups "v8-users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > >> For more options, visit https://groups.google.com/d/optout. > >> <onlyppudeopt.txt><tickmethod.txt> > > > > -- > > -- > > v8-users mailing list > > [email protected] <javascript:> > > http://groups.google.com/group/v8-users > > --- > > You received this message because you are subscribed to the Google > Groups "v8-users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
