Problem with multiple using of 'Trim' filter in Avisynth

[Balbes]

Does anyone know how many Trim operations can be handled? Or How does Avisynth handles its scripts?
I am trying to compress m2ts into mkv using MeGUI but problem is with source file - it has very unstable noise. Somewhere a little noise, somewhere heavy or moderate and somewhere no noise at all. So I decided to use some noise filters, trimming video to zones for different settings, such as:

vid=LWLibavVideoSource("F:\Logic.m2ts")
vid1=vid.Trim(0, 1055).<filter1(settings1)>
vid2=vid.Trim(1056, 3488).<filter1(settings2)>
vid3=vid.Trim(3489, 5566).<filter2>
vid4=vid.Trim(5567, 7353).<filter1(settings2)>
...
vid1++vid2++vid3++...++vidxx

And that's where problem surfaced: Avisynth begins to work unstably and eventually crashes (if MeGUI didn't crash beforehand), throwing an exception (out of memory) with more than 6-8 of those cuts. And I have at least a couple of dozens of those! All of tested noise filters works fine when being put on entire video (instead of trimmed clip). And no one of them does a perfect job due to instability of noise - some blurs scenes with little noise (doing a decent job with heavy noised ones), some can't properly handle scenes with motion, etc.
Even one and the same filter with same settings, like

vid1=vid.Trim(0, 1055).<filter1(settings1)>
vid2=vid.Trim(1056, 3488).<filter1(settings1)>
vid3=vid.Trim(3489, 5566).<filter1(settings1)>
vid4=vid.Trim(5567, 7353).<filter1(settings1)>
...

(did that just for testing purpose) leads to crash of Avisynth.
What can I do? I don't quite understand why it's happening. Is Avisynth prepares all of the source before feeding it to encoder (and preparing many different segments uses a lot of memory)? Is there a way to split its job to manageable segments? Or am I really shall be forced to break source into several dozens small clips, process them separately and glue them together in the end?

[Budman1]

http://avisynth.org.ru/docs/english/syntax.htm talks about setmemorymax(int) filter. You may be limited here or need to set it higher.

SetMemoryMax (int): Sets the maximum memory that AviSynth uses (in MB). Setting to zero just returns the current Memory Max value. v2, (=0) v2.5.8

In the 2.5 series the default Memory Max value is 25% the free physical memory, with a minimum of 16MB. From rev 2.5.8 RC4, the default Memory Max is also limited to 512MB.

Free memory: <64 128 256 512 1024 2048 3072
Default Max v2.5.7 and older: 16 32 64 128 256 512 768
Default Max since v2.5.8 RC4: 16 32 64 128 256 512 512
In some older versions there is a default setting of 5MB, which is quite low. If you encounter problems (e.g. low speed) try to set this values to at least 32MB. Too high values can result in crashes because of 2GB address space limit. Return value: Actual MemoryMax value set.

[manono]

I very much doubt it's the use of the trims, but the multiple use of the denoiser.

[Balbes]

Even without that memory setting avs4x264mod already uses about 1100MB of RAM during encoding process (plus about 800MB by x264), so I think I pretty much capped there (though there are still about 13GB of free memory - it doesn't matter for x86 processes with their 2GB limit).
I know that my settings are pretty heavy (for example: TemporalDegrain(degrain=3, ov=4, blksize=16)) but why they stack after being used? They are not affecting each other after all. Isn't there a way to shorten lifetime of some variables? For example: if I processed the current segment and fed it to the encoder - isn't logical, that It is no longer needed and will be eliminated, freeing valuable memory for the next segment? I thought any programming language works like that. Or Avisynth can't?
Tried to use functions (since local variables will live until function is alive), but no luck. Either you must delegate segments into function (otherwise it wouldn't see those segments) or declare them globally. Both cases leads to indefinitely living segments littering the memory, it seems... At least I can't see another explanation here. Why else single-segmented denoising for the clip works perfectly fine and multi-segmented the same denoising for the clip crashes?

[hello_hello]

It's possible it relates to this problem: http://forum.doom9.org/showthread.php?t=172744
Towards the end of the thread VideoFanatic has been reporting crashes, but I haven't kept up with the thread.

If it is related, I found using multiple Trims with "complicated" filtering (mostly QTGMC for me) would be likely to cause slowdowns.

And if it is related, it effects older versions of Avisynth too, but so far the cause remains unknown.

On a few occasions I did give up and created multiple copies of a script, each with a single Trim(), then appended the encoded video together. Don't forget to add --stitchable to the x264 command line.

[manono]

Depending on how many different denoiser settings you have, you might try and do it this way:

A=Last
B=A.DenoiseFilter(Settings1)
ReplaceFramesSimple(A,B,Mappings="[0 1000] [4000 5000] [9000 10000]")
A=Last
B=A.DenoiseFilter(Settings2)
ReplaceFramesSimple(A,B,Mappings=[1001 2000] [5001 6000] [8001 8999]" ")
A=Last
B=A.DenoiseFilter(Settings3)
ReplaceFramesSimple(A,B,Mappings="[2001 3000] [6001 7000] [10001 11000] ")
A=Last
B=A.DenoiseFilter(Settings4)
ReplaceFramesSimple(A,B,Mappings="[3001 3999] [7001 7999] [11001 12000] ")

It's way more efficient than all the trims, anyway. No guarantees it won't crash. And you're not using any multi-threaded versions of AviSynth, are you? ReplaceFramesSimple requires stickboy's RemapFrames fiter.

[Balbes]

You're a savior, sir! May my prayers will be with you... tuesday, from two to four pm.
But seriously - it works! Drastically slow, but without any errors and crashes. So far...
Well, I think my case is closed then. Though there are still remains a question about how avs are being handled (or about Avisynth cleaning its own garbage).

I found using multiple Trims with "complicated" filtering (mostly QTGMC for me) would be likely to cause slowdowns.

Yeah, I did use it too. It have its own denoise script after all. Something like:

QTGMC(InputType=1, Preset="slow", NoisePreset="medium", EZDenoise=3.0)

Gives fairly decent results. And in some cases better than TemporalDegrain. But slow, yeah.