prostitutin aint easy ®™©
I was comparing altbinz vs. UE, and indeed UE has a fraction of the processor load at the same download speed, maybe somewhere around 15%-25% of what altbinz consumes. Altbinz still uses a 'old school'(actually 2nd generation) method (that UE also used a few revisions ago) of writing downloaded articles to disk, then decoding them into rars when enough finish to complete a rar -- while UE creates an eDonkey/Bittorrent-like dummy file at the start of the download - one for every rar- then slowly fills it in with (decoded) articles as they download. This is one big difference between them as far as their download mechanism goes.
It seemed that many of the "first generation" binary newsreaders used a rather queer one-connection-per-rar method that allowed for fast initial download, but then caused computer lockup because all the articles composing each of the rar files would finish at about the same time, so all these rars would decode at about the same time, pegging out the processor. As well as the many other problems that one-connection-per-rar created, I never understood why any newsreader developer back then chose to process binaries this way. (as well as why the Newsflash Plus developer even today insists on this method)
But then emerged Altbinz and the '2nd' generation usenet download clients (not quite newsreaders w/o header support) at least would complete a full rar before starting on the next one, so decodes would overlap throughout the download. I could not notice any visual (eyes on graph) improvement in resource efficiency between the old and new altbinz (if anything it was the opposite) and article decoding still resulted in a hefty processor hit. A difference in settings (default vs. tweaked-years-ago) could have been at least partly responsible for the apparent hunger of v39.4. This was running XP, on a 10 year old laptop that doesn't even handle a lot of recent Java or Python applications very well.