"Saving package, this may take a while..." Question for Vlk, Igor.

[Vladimyr]

Hi.

Someting Vlk said here: http://forum.avast.com/index.php?topic=31426.msg261982#msg261982 specifically:

@Vlk post:32

Unfortunately, this feature will not work under Vista until Avast 5. There’s no easy way to fix this (in avast 4.x, the updater and all its GUI run in the context of the service, which is not allowed to draw anything under Vista).

got me thinking about how/whether the auto updating was likely to change as Avast! is further developed.

For some time I’ve been perplexed by the long apparent pauses between downloading increments during which the message:
“Saving package, this may take a while…” (‘Avast_2-15.jpg’)
is displayed when automatic updating on a older PC with Windows 9X that’s not been used for a week or two. In these cases it’s typically faster to download (2 minutes) and run (8 minutes) the latest VpsUpd.exe than to wait 20 to 40 minutes (see ‘Avast_update.jpg’) for the auto updater, which seems to spend at least 70% if its time “Saving package”(s).

Now,the intriguing bit. My assessment is that the amount of time taken, and the percentage of that time displaying “Saving package, this may take a while…” seems to be more dependent on RAM than CPU speed.
E.G. the example in ‘Avast_update.jpg’ (27 minutes) is for a 98SE machine with 200mhz processor and 90MB RAM, whereas another 95OSR2 machine with 200mhz processor but only 48MB RAM took about 45 minutes for the same update.

1. Why does it take such a relatively long time to save the small incremental packages?
2. Is this apparent RAM-related difference in speed consistent with the resource demands of the updater or are other factors likely to be causing the time difference?
3. I don’t imagine that it would be a high priority ;D but is the auto updater in the next version of Avast likely to be more or less cumbersome on such “ancient” hardware as this?

[system]

We will probably not change it for an ancient hardware.

The “saving” is quite straghtforward. It decompresses two buffers, creates the third, performs diff and then compresses the third buffer again. I can guess that one diff step of VPS may take about 40-50MB of ram. That’s probably why it is crawling on your machine.

Since this was made with “better safe than sorry” approach, it does the mentioned operation for each diff step (which may sound stupid because it compresses/uncompresses the very same file again and again).

Also, the whole updating is optimized regarding to sizes of downloaded files.

[Vladimyr]

Thanks kubecj, your explanation makes sense.

Actually I “misunderremembered” (sorry Mr President) when I said one PC had 90MB, it’s 80MB.
Clearly, if I want to even consider using the Avast auto-updater without the long delays and “pain” of swap-file paging on the PC with 48MB RAM , I really should go for the “radical” upgrade, take out the original 2 x 8MB 72pin EDO RAM modules that came installed in the machine back in 1997, and replace them with the 2 x 32MB ones that have been sitting on my desk for the last 6 years! :-[ (Wow! a whole 96MB. Just think how fast FF1.5 would load then!) ;D

I don’t expect that any Avast changes will be focused on “ancient” hardware and/or OS. It’s very good that Avast still works so well on these machines. Perhaps just a link to the ‘VpsUpd.exe’ download could be added to the “About” box. I wonder if many Avast users forget this option?

[system]

You know, bytes cost, so the less number of users download 9megs instead of few diff kilos, the better.

[Vlk]

As far as I know, the speed of the “saving package” step (or slowness thereof) has always been caused by the digital signature processing.

That is, after each file is downloaded, the updater verifies its digital signature. And this is a CPU intensive thing.

[Vladimyr]

Thanks guys!

@kubecj post:4

You know, bytes cost, so the less number of users download 9megs instead of few diff kilos, the better.

…a valid point.

[system]

It may be related to your ethernet card or modem.

[Vladimyr]

@RJARRRPCGP post:7

It may be related to your ethernet card or modem.

In what way?

[DavidR]

@RJARRRPCGP post:7

It may be related to your ethernet card or modem.

I think kubecj and Vlk explained the most likely scenario for this in their posts, a ethernet card or modem are unlikely to be the bottleneck in this case, especially when we are talking about small incremental updates.