More to point.. it all depends.
CPU emulation is a limiting facotr in simpler machines, but in more complex emulations, its usually the interplay between processors and the complex rendering. ie: A SNES is not too difficult to emulate at all, but its rendering that makes it slow a hell.. simulating hardware in software is rough.
Handy on the other hand.. has always been slow; I never looked into why, but that sucker always chugged more than I thought it should.
My first guess, without lookiung at the code in a decade, is that he proabbyl calsl too many fucntions or sometyhing.. perhaps hes depending on a good aggressive c++ compilation, and the fucntion calls are going through vtables or something.. ie: Good C++ is just as fast as anythign else, but if hes depending on some ugly c++ features, it could get goofy. But hopefulyl hes got it simple and full of inlining and it shoudl run fast..
But even then.. a funciton call to handl eeach opcode isn't so bad.. that doesn't really slow it down that much on a gp32 (ie: CaSTaway uses a funcall per opcode, through either an array of funptrs or through a giant switch statement, and both are plenty fast).
So in the end its liekly the desing of the emu, or perhaps its threottling waiting for certain cpu state to occur in sync, or other artificial limits.. or maybe its jsut the fact theres 2 or 3 little cpus going on there, and they're using floating point or something..
So dig through the code; you can't just guess.. you need to understand the design (the intercpu stuff); is it float based a lot (kills performance on gp32 badly), or ...
(assuminfg you've already done the display, thats one main part ruled out; or maybe even with assembly its still slow to render
jeff