having written all this codewe are finally able to test whether thread pools or process pools give us better performance created large ( pixelsblack and white image and ran it through both pools the processpool takes about seconds to process the image on my systemwhile the threadpool consistently takes about thusas we suspectedthe cost of pickling bits and bytes back and forth between processes is eating almost all the efficiency gains from running on multiple processors (though looking at my cpu monitorit does fully utilize all four cores on my machineso it looks like compressing single image is most effectively done in separate processbut only barely because we are passing so much data back and forth between the parent and subprocesses multiprocessing is more effective when the amount of data passed between processes is quite low so let' extend the app to compress all the bitmaps in directory in parallel the only thing we'll have to pass into the subprocesses are filenamesso we should get speed gain compared to using threads alsoto be kind of crazywe'll use the existing code to compress individual images this means we'll be running processpoolexecutor inside each subprocess to create even more subprocesses don' recommend doing this in real lifefrom pathlib import path def compress_dir(in_dirout_dir)if not out_dir exists()out_dir mkdir(executor processpoolexecutor(for file in for in in_dir iterdir(if suffix =bmp')out_file (out_dir file namewith_suffix(rle'executor submitcompress_imagestr(file)str(out_file)def dir_images_main()in_dirout_dir (path(pfor in sys argv[ : ]compress_dir(in_dirout_dirthis code uses the compress_image function we defined previouslybut runs it in separate process for each image it doesn' pass an executor into the functionso compress_image creates processpoolexecutor once the new process has started running