Closed GoogleCodeExporter closed 8 years ago
VSFilter 2.39
~2GB RAM
100% avg single-threaded CPU utilization
Unable to play smooth (Core i5-750 @3.2Ghz)
VSFilter 2.40
~2GB RAM
100% single-threaded CPU utilization
Unable to play smooth (Core i5-750 @3.2Ghz)
xy-VSFilter 3.0.0.8 = ~1.5GB RAM
~1.5GB RAM
Brief 50% max single-threaded CPU utilization then near 0% since everything is
cached
Able to play smooth (Core i5-750 @3.2Ghz)
At some point we'll need to look into seeing if memory consumption can be lower
in this case.
This isn't a regression, and I suspect not even a bug, so I'm marking this as
an Enhancement.
VSFilter's routine for rendering gradients probably is just bad code (like much
of legacy VSFilter code) which has high memory utilization by design. Until
YuZhuoHuang takes a look at it, I won't have a good sense if this can be
improved upon or not. If this is a GDI limitation, we may be stuck.
Original comment by cyber.sp...@gmail.com
on 6 May 2012 at 4:09
The next build we release should reduce the memory footprint as well as offer a
performance improvement for anything which uses /clip.
MPC-HC (VMR9 renderless NV12) + Haali Splitter + LAV Video on Win7 x64
= ~179.5MB used w/ xy-VSFilter in graph with InsaneMemoryUsage.mkv
= ~180.5MB used w/ xy-VSFilter in graph with InsaneMemoryUsage script with
/clip removed
= ~116MB used w/o xy-VSFilter in the graph with InsaneMemoryUsage.mkv
Current progress shows xy-VSFilter now actually consuming 1 MB _less_ compared
to the script with all instances of the /clip created gradient removed. CPU
utilization for InsaneMemoryUsage.mkv also seems to have been cut in half
compared to 3.0.0.8
Original comment by cyber.sp...@gmail.com
on 11 Jun 2012 at 3:43
Attachments:
Fixed in xy-VSFilter 3.0.0.40
Original comment by cyber.sp...@gmail.com
on 20 Jun 2012 at 5:52
Original comment by cyber.sp...@gmail.com
on 20 Jun 2012 at 5:53
Original issue reported on code.google.com by
tp7...@gmail.com
on 6 May 2012 at 12:26Attachments: