unexpected Patch sizes

[jlsf2]

I have a project with 4 versions in it. Depending on the changes made to the application, and in order to reduce the size of downloads required by the user, I will create different patch files that support different versions.
e.g. patch file #1 that goes from v1/v2/v3 -> v4
patch file #2 that goes from v3 -> v4

Previously, I had a patch file:
v1/v2 -> v3, size == 2.8MB

With my latest release, I have created these two patch files:
v3 -> v4, size == 3.8MB
v1/v2/v3 -> v4, size == 11.5MB

I've tried similar things in the past with VP2/VP3 and things have been optimized pretty well.

This though seems like something is seriously wrong with the optimizer... In the worst case, I would expect my largest size patch to be only 6.6MB (2.8+3.8).

Any ideas what is going on here?

[SteveDude]

Are you using any compression software for your app. I heard that will make patches larger.

[Lorne]

The multi-version patches aren't internally sequential -- Visual Patch isn't creating diffs to go from 1 to 2, then 2 to 3, then 3 to 4. It's creating diffs to go from 1 to 4, and 2 to 4, and 3 to 4.

In other words, it does multi-version patching in parallel.

Which approach is better depends on the situation. Sometimes a sequential approach will generate smaller patches, sometimes a parallel one will. One of the items on my list of future optimizations is to have Visual Patch build both kinds of diffs (parallel and sequential) and then choose between them.

In your case, jlsf2, it sounds like there more changes between the first two versions and version 4 than there were between them and version 3. You might want to consider keeping the 1-2-3 patch, and then just using the 3-4 patch (and go on from there).

(If you use TrueUpdate, you could automate the whole process and use sequential patches for the smallest possible patch files.)

[jlsf2]

Regarding the use of compressed files - do you have a thread reference for that?

[SteveDude]

It's here

http://www.indigorose.com/forums/showthread.php?t=21481

[Lorne]

Regarding the use of compressed files - do you have a thread reference for that?

It's just a general property of binary differencing.

Binary differencing relies on finding similarities between two files.

Most compression methods hide those similarities to the point where two versions of a file appear internally as two completely different files. It's harder to find matching patterns between the files, because all their patterns have been reduced and reconfigured, forming completely new patterns.

Instead of seeing the changes that were made to the original file, you end up seeing the differences between how the compression method describes the two versions.

The DeltaMAX patching engine used in Visual Patch is very good at finding similarities between files. But it will usually achieve much better results on files that haven't been compressed.

(This is also true for files that have been encrypted. With encryption, as with compression, the file's original patterns are hidden on purpose.)

[jlsf2]

Ok, compression isn't a problem for me.

Lorne, I can see where that could happen, although it seems like more of a border case where serial would be better (of course, it would help in my situation).

Implementing both serial and parallel comparisons seems like it could get awful messy - to get truly the best implementation, you'd want to mix and match serial and parallel from version to version - and that could grow to far too many cases to check.

I guess just doing an all serial or all parallel would be the simplest approach and would likely get you 90% of the benefit.

Thanks for the info.

[Lorne]

Originally Posted by jlsf2

Lorne, I can see where that could happen, although it seems like more of a border case where serial would be better (of course, it would help in my situation).

Implementing both serial and parallel comparisons seems like it could get awful messy - to get truly the best implementation, you'd want to mix and match serial and parallel from version to version - and that could grow to far too many cases to check.

Yes, there would be a lot of combinations, but it wouldn't affect build times much if diff caching was enabled. It's still something I'd like to try in the future, but it isn't a high priority since parallel patching works very well in the majority of multi-version patches. It's also completely irrelevant for single-version patches (which are already sequential).

I guess just doing an all serial or all parallel would be the simplest approach and would likely get you 90% of the benefit.

True, but it wouldn't be quite as cool.