Patch generation hangs system?

[jassing]

I had produced a file that was 98 megs; there was only a very small change in it; so I wanted to see if a patch would be substantially smaller; so I could email the change vs. upload the file...

Twice I tried to generate it; twice my system locks up... the caps lock light etc won't work -- but I can still ping the system.
I cannot use network shares,etc.

Is there a binary size limit?

[jassing]

D'oh! Posted to the wrong forum, sorry.

besides, built it on another machine; and it successfully built a patch in no time at all...

Very odd.

[Lorne]

The size limit is around 2 gigs for any individual source file and for the resulting diff. (The engine can theoretically handle larger sizes with a few changes but we're using bits and pieces of other code that imposes the ~2 gig limit.)

98 megabytes is a piddly little bit of data for our patch engine.

If I were to take a guess: for some reason the virtual address space for the VP process on that system is heavily fragmented, or the system has very little contiguous virtual address space available.

[jassing]

Thanks Lorne.
yes; as I discovered when I moved it to a different system -- built the diff in no time at all...
No matter what; a system lockup isn't good under any situation... (just my $.02)
Thanks again tho.
Oh -- and sorry for posting to the wrong forum...

[Lorne]

Thanks Lorne.
yes; as I discovered when I moved it to a different system -- built the diff in no time at all...
No matter what; a system lockup isn't good under any situation... (just my $.02)

I agree! Although if my hunch is correct, the system might not technically be hung, it may have just been put into a very resource-constrained state. If the source file indexing gets forced into paged memory (so the hash table processing occurs on disk), it slows things down exponentially.

However, I've never seen the engine hit that behaviour in tests with production code; the only times I've seen it happen was during development, when I made stuff like that happen on purpose. (Over, and over, and over, and over... )

The engine is designed to prevent that kind of situation from occurring; it checks resource availability before each compression attempt and adjusts all of its buffers and settings to fit in the available commitable address space, with extra room left for "unknowable unkowns." DeltaMAX is actually able to operate in very tight memory situations (at the cost of slightly larger diff sizes) by relaxing its settings automatically.

[jassing]

I agree! Although if my hunch is correct, the system might not technically be hung, it may have just been put into a very resource-constrained state. If the source file indexing gets forced into paged memory (so the hash table processing occurs on disk), it slows things down exponentially.

Possible, I guess, but I left it sit for over an hour....
You could ping it; but caps lock didn't work (keyboard light didn't change) ctrl-alt-del did nothing; you could not use network resources (that were previously attached to the machine "The network resource is no longer available"