Making Binary Diff a little more intelligent...
Posted: Tue Aug 24, 2010 7:34 am
Here an example:
Well that lack of 'intelligence' is present in EDP for about 2 or 3 years.
Hmm but maybe no one else had noticed - or dropped a note about it. Okay the result is correct block comparison size 1 Byte. However beside this and the other solution were else a '66' can be found, there is one that is the best and that is the '66' right before the match block.
This is just my idea on how to do it - let's call it smart compare or optimized compare :
To implement this makes some little efforts, but it's probably no big deal.
According to the result I guess you scan the file downwards and forwards when comparing.
Well after you've done that you should do a optimization run upwards and backwards that tries the concatenate match blocks.
To better show let's say the SourceMatchblock with only '66' is '42 00 66' instead.
then the optimization run would take out '66' from that Block '42 00 66', start at the DestinationMatchblock '0c 00 00...' and look upwards for another '66'...[think and guess the rest of that algo]
Then the same for '00' 'and '42' and adjust/move both matchblock.
And on other thing:
* In the option for compare it would be nice to also set the compare Window size. That's the area where EDP will look for inserted/delete blocks if a difference is found. Now I guess maybe now it's the whole file - however if the file is a little bigger(like 2MB or 3MB) that'll just take very long to compare. To limit that to may 200KB or what ever you like will be a create trade off and speed up binary compare of will make it possible for bigger file.
- ED_5_18.PNG (34.72 KiB) Viewed 5388 times
Hmm but maybe no one else had noticed - or dropped a note about it. Okay the result is correct block comparison size 1 Byte. However beside this and the other solution were else a '66' can be found, there is one that is the best and that is the '66' right before the match block.
This is just my idea on how to do it - let's call it smart compare or optimized compare :
To implement this makes some little efforts, but it's probably no big deal.
According to the result I guess you scan the file downwards and forwards when comparing.
Well after you've done that you should do a optimization run upwards and backwards that tries the concatenate match blocks.
To better show let's say the SourceMatchblock with only '66' is '42 00 66' instead.
then the optimization run would take out '66' from that Block '42 00 66', start at the DestinationMatchblock '0c 00 00...' and look upwards for another '66'...[think and guess the rest of that algo]
Then the same for '00' 'and '42' and adjust/move both matchblock.
And on other thing:
* In the option for compare it would be nice to also set the compare Window size. That's the area where EDP will look for inserted/delete blocks if a difference is found. Now I guess maybe now it's the whole file - however if the file is a little bigger(like 2MB or 3MB) that'll just take very long to compare. To limit that to may 200KB or what ever you like will be a create trade off and speed up binary compare of will make it possible for bigger file.