The bottlenecks are typically the broad base support,
as well as extensive debug support.
The code has been written to allow a fast turn around
if something breaks or needs addition.
We are using approx 40:1 instructions simulated-real, so expect
Your processor clock-rating/40 speed on *average*.
(Ive seen sims at 12:1 for a few thousand $$$)
A general answer is correct, since unless you reduce the
*average* real to simulated instruction count, you wont notice
a difference.
The largest increase in speed would be to rewrite dosbox
so that it has a seperate image for each possible combination
(eg Ega & SB), and only essential SDL calls are integrated.
Then rewrite the sound/video code into the same simulator
(at the moment its running as 2 virtual machines)
Replace threaded code with Hand crafted loops.
Use a static memory size, locked at startup.
Then write a windows low-level driver to give clean fast access
to memory and disk (one for windows 95/98, one for ME, one for XP/NT, one for the mac's, one for ...)
Then finally use a "profiler" to figure out the last loops that dosbox
spends too much time in, and optimise those to be inline assembly.
In 5 years... does anyone care? Processors are 4 times faster.
(And then someone points out an instruction you 'missed',
or a feature they *need* ...)
This is a hobby, not a job.
p.s. I've noted the biggest increase in speed is from a *real* OS,
Linux. Try it sometime.
p.p.s To answer the exact question you asked, the problem is
under what test conditions do you define "slow".
Answers like Protected Mode game dont count, we need
something like game X, calls int21 every 100ms and generates
a page fault every 2seconds.