I've noticed the gui seems to lag while the timeout functions are running.

That's the problem with cooperative multitasking (event loops).

You have to balance the needs of being responsive to interactive routines and getting work done in cpu intensive routines. Manually. By either breaking the cpu intensive bit up into iddy biddy chunks or interspersing your loops with yeilds. And just when you get the balance right on your machine, you'll have to re-tune it to run on a faster machine, or a slower machine. Or both.

And just when you think you've got that cracked, someone will call for the addition of another background task and you'll have to do the balancing act all over again. And when you've cracked that and the code goes into the field, although the users are running teh same hardware as you, they are also running another cpu-intensive program concurrently that saps half of the available cycles. That means your carefully partitioned loops now take twice as long as they do on your machine and once again, the gui becomes sluggish.

Pre-emptive multitasking (threads) does not suffer these problems. Whatever hardware you run it on, and whatever the current cpu load, except for in extreme circumstances, the OS scheduler will ensure that your gui gets sufficient and timely slices of the cpu to remain responsive. That's why threads were invented.