RE: PicoBlaze Simulator in JavaScript
August 18, 2022 at 10:10 am
(This post was last modified: August 18, 2022 at 11:29 am by HappySkeptic.)
Please learn to use the Developer (F12) console in Chrome.
Performance testing your Decimal to Binary when using FastForward shows that the time is almost 100% your setting (and the rendering) of DOM elements. I haven't tested the compiler - I presume that isn't what you are complaining about.
Also, your use of a timer to instantiate the next instruction is a good idea "IF" you want every instruction to show on screen, but terrible if you want performance. The timer event will go in the back of the queue, and the DOM update work will be done first.
Looking at the source after the profiling in the F12 dev console even shows timings for certain hot spots. It is all about changing the innerHtml or innerText of your DOM elements (and the Paint time to render them).
You can even debug through the run to make sure you aren't doing the same work 100x or some other bad thing, but otherwise it looks like your html work.
In "real" programs, one would do as much work as possible in one frame, and then do the DOM update once per frame. This is done by calling requestAnimationFrame(), and only doing the DOM work on that callback (and only doing DOM work if at least one command has been executed since the last update).
You could still use your timer for scheduling each instruction, but it would run 1000x faster than current. A timer for each instruction is not fast either, because of the overhead in scheduling the microtask, but is nowhere near the performance problem you have now.
One other note - I don't know if this is a problem or not in your GUI, but don't use the DOM as your state. If you do, you can't get around adjusting it on every instruction. The DOM is a view of your state, not the state itself. So, you should be able to run 1000 instructions before updating it. If your design doesn't allow that, you haven't designed it well.
Also - logging to the console slows things down, especially when that console is open, but slightly even when its not. Make sure you only log at spots where you don't care about performance. Often I'll put some global "enableLogging" flag, and only log if that is on (if I'm not already using a proper logging framework).
Performance testing your Decimal to Binary when using FastForward shows that the time is almost 100% your setting (and the rendering) of DOM elements. I haven't tested the compiler - I presume that isn't what you are complaining about.
Also, your use of a timer to instantiate the next instruction is a good idea "IF" you want every instruction to show on screen, but terrible if you want performance. The timer event will go in the back of the queue, and the DOM update work will be done first.
Looking at the source after the profiling in the F12 dev console even shows timings for certain hot spots. It is all about changing the innerHtml or innerText of your DOM elements (and the Paint time to render them).
You can even debug through the run to make sure you aren't doing the same work 100x or some other bad thing, but otherwise it looks like your html work.
In "real" programs, one would do as much work as possible in one frame, and then do the DOM update once per frame. This is done by calling requestAnimationFrame(), and only doing the DOM work on that callback (and only doing DOM work if at least one command has been executed since the last update).
You could still use your timer for scheduling each instruction, but it would run 1000x faster than current. A timer for each instruction is not fast either, because of the overhead in scheduling the microtask, but is nowhere near the performance problem you have now.
One other note - I don't know if this is a problem or not in your GUI, but don't use the DOM as your state. If you do, you can't get around adjusting it on every instruction. The DOM is a view of your state, not the state itself. So, you should be able to run 1000 instructions before updating it. If your design doesn't allow that, you haven't designed it well.
Also - logging to the console slows things down, especially when that console is open, but slightly even when its not. Make sure you only log at spots where you don't care about performance. Often I'll put some global "enableLogging" flag, and only log if that is on (if I'm not already using a proper logging framework).
