Avisynth 2.04 is SLOOOOW !!! What gives?

[Guest]

I just installed 2.04 and ran the same AVS on it and 1.0beta5. Here are the results:

2.04 ~9 fps
1.0beta5 ~21 fps

Here is the script:

LoadPlugin("d:\don\programming\c++\avisynth\decomb\release\decomb.dll")
avisource("g:\tmp\bebop.avi")
t=Telecide(post=false,guide=1)
Decimate(t,mode=2,threshold2=100,debug=true)
##Subtract(t.Trim(1,0),t)

Are we making giant backward steps with this project or am I doing something wrong? Thank you.

[dividee]

Can you try by adding
SetMemoryMax(40)
at the start of the script?
Since 1.0beta6, the memory usage of avisynth has been severly limited (only 5MB for frame buffers). That's why I added this script function to allow more control. The previous scheme was to allow 1/4 of the amount of RAM for frame buffer, but apparently this caused problems for some users. But 5MB is very low, I think we should change that in the next version.

[WarpEnterprises]

Wouldn't it be good to add such infos to the Version() output?
(I'm thinking of memory usage/settings, plugin_dir, ...)

[sh0dan]

How about 1/4 of physical memory, but a limit at 64MB - and then it can be overriden with SetMemoryMax().

[dividee]

I was thinking about something based on the available physical memory at the time avisynth starts, so it should never trash to virtual memory, whatever the number of instances running concurrently (unless all instances are launched at exactly the same time).

[droolian01]

Hi there dividee and all.

I've started using version 2.04 on a brand new ( and much faster) machine i've built, so can't comment on the speed differences between different versions.

I am curious about the argument for SetMemoryMax. Does SetMemoryMax() allocate all the available physical memory on being called? Does SetMemoryMax(40) (listed above) allocate 40 MBytes or 40%or whatever?

It have been very pleased with the speed increase with my new hardware setup - but it would be really cool to get even more fps during encoding!

Thanks.

[Richard Berg]

40MB.

http://www.avisynth.org/index.php?page=ScriptFunctions

[droolian01]

Thanks.
Nice link with updated faqs (i was still using the original one!)
More testing after work!

[Guest]

@dividee

Yes. Setting max memory to 40MB cleared the problem. I think this is a serious issue with the current version. There's no warning anywhere and if people don't know they will unnecessarily throw away over half their performance! I just happened to notice a massive slowdown when I installed 2.04. :)

@droolian01

It's not an issue of how fast the machine is. Mine is an XP 1900+ with 512Meg of RAM and a fast disk. It might be even faster for you with this memory increase!

[trbarry]

The memory thing could be an issue in another way. I sometimes use GreedyHMA (or Decomb?) with DirectShowSource or other input that does not necessarily have complete support for random seeking. But GreedyHMA does indeed read records randomly and I've usually felt I could get away with it because records read out of order will usually be within the last 5-6 records read, and therefore already in Avisynth buffers.

But if the random record requires actually going back to the file instead of buffer cache then it is not only a possible performance hit but also may cause errors for some of these filters. And since I'm often reading 1920x1080 sized records I could eat up the available buffers pretty quick.

So it is nice to know about the memory condition and the override command.

Thanks, :)

- Tom

[Guest]

@trbarry

How could going back to the disk versus the frame cache cause problems other than performance ones? Accessing the frame cache randomly should present the same problems as accessing the file system randomly. No?

[trbarry]

neuron2 -

Well, correct me if I'm wrong, but if you have just read record 10 and you choose to next read record 5 then Avisynth will probably just ask for record 5. But I'm not sure that some decoders can gracefully read backwards. When they are going forward they can just chug through the records, and some do. DVD2AVI, for instance, will check to see if the record you are asking for happens to be one more than the last one and take an optimized path.

But I don't think full random access always works with DirectShowSource or some other decoders.

But Avisynth's cache is (I think) by clip & frame number and if he's already got it then all is okay.

- Tom

[Guest]

@trbarry

I get it now. Thanks for the explanation.