Slow down a `split`

I have a really large archive consisting of really small files, concatenated into a single text file, with a "" dilimiter. For smaller archives, I would split the archive using "" as a pattern, and then work on the resulting files. However, in this archive there are on the order of magnitude of a hundred million such files -- clearly, too much for putting them all into a single directory. I have created folders aa, ab, etc. for trying to move them into directories as they are created. However, I ran into issues. Things I've tried: 1) There is no command for split to execute any command on the resulting file. So I have to do it by hand. 2) Moving the files into the ** directory using `find . -name "xaa*" -exec mv {} aa \+ does not work because {}` is not at the end of the line. 3) The -t flag, for reversing the source and the destination, is not available in my version of Unix. 4) I had to pipe the output of find into xargs, for it to work out. However, this is too slow -- files are being created way faster than they are moved away. 5) I suspect that xargs is processing less files at a time than using a \+ after find -exec. I tried adding a `-R 6000' flag, for running 6000 entries at a time; however, I don't think it made a difference. 6) I decreased the priority of split to the lowest possible. No change in the amount of CPU it consumed, so probably no effect either. 7) I open up to seven command prompts for running the mv commands (last four letters per command prompt) -- however, this is still not nearly enough. I would open more, but once the system gets to seven, the response is so slow that I have to stop the split. For example, the source archive got copied to a USB all while waiting for a ls -l | tail command to return something. So what I've been doing is, stopping the split at that point, waiting for the mv commands to catch up, and then restarting the split. At that point I would use find -exec rm {} \+ to delete the files I already have; this is a bit faster, so when it gets to the files I don't have, there's less files around. So the first such iteration lasted ~3 million files, the next one ~2 million, the next ~1.5. I am sure there should be a better way, though. Any ideas for what else to try?