Well, for when I did run Windows last time with a webserver on it, I used Xampp, and it wasn't too slow out of the box. I found I still had to change portions of my.cnf to get it to run at a decent pace.
Several installs and jumps between Linux and Windows has made me realise that most of the Windows stacks I've come across have a lot to be desired performance wise and fiddling with my.cnf yields the best improvement.
Currently I use a 9 year old pc for most dev work, running Ubuntu server. It was painfully slow, but setting up MySQL caching to be a bit more reasonable and installing APC now has it running much, much faster than my quad core (with Xampp, admittedly no apc) at a mere 3 years of age. (The server only has 768mb of RAM).
My suggestion is to dive into my.cnf, though back it up first because if you get it set up wrong it may run much slower.
Alternatively get yourself set up with an Ubuntu server, made my life much easier (Though be prepared to lose several hours, maybe more if you are adverse to using a terminal) The Ubuntu Server guide walks you through pretty much everything you will need to do though.
As a disclaimer I have never used Uniform.
Edit from here on:
Relevant settings I use for my.cnf are:
[myslqd]
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
# I keep this low to limit max memory usage, with 2 or less people we don't get near this
max_connections = 50
# table_cache is quite large compared to default because of the massive amount of tables
# Drupal uses.
table_cache = 512
# Increased for those large queries, though keep an eye on these queries exceeding this
# value on your production server/hosting.
query_cache_limit = 3M
# Greatly increased due to the large numbers of queries Drupal does.
query_cache_size = 32M
# Total size of InnoDB's buffer, larger is better, I keep it larger than the DB of the
# of the site I am currently working on.
innodb_buffer_pool_size = 128M
# This stops InnoDB flushing its log at every transaction, instead flushiong it once
# per second. Can be detrimental to the last 1 or 2 seconds of data in case of a crash.
# Imo provides the largest boost on desktops due to their usually limited I/O capacity.
innodb_flush_log_at_trx_commit = 2
I no longer use myisam tables so I haven't played with myisam specific settings in there.
Overall the biggest bottleneck is hard drive access time so I keep as much in memory as possible, my dev server (Which is that ancient desktop box) has PATA drives so even writing to its miserable 8MB cache is slow. If your computer is low on I/O you need more caching, APC also makes a big difference in these cases.
Just keep in mind that you should compare the production environment settings to your dev ones to make sure that you stay within the production environment capabilities, though even on shared hosting with dismal caching and no APC, the presence of RAID usually makes up for it (Granted though that the host we use currently is the fastest one we have used, and some shared hosts are going to be slow no matter what you do.).
Also look at http://www.mysqlperformanceblog.com/ but also maybe avoid it because that is more geared towards dedicated database servers with obese amounts of RAM.
