Insame amounts of RAM used. Memory Leak?

[lediafru]

I just registered only to report this issue: I looked into the task manager when the game I was playing with a PS4 controller started stuttering and saw that DS4 Windows used 7.3GB of RAM. Could there possibly be a memory leak? I'm using Version 1.5.8 x64 by the way.

[m-7761]

P.S. In (friendly) reply to earlier sharing of projects; I recently completed 2.5 grueling months of work (https://sourceforge.net/p/collada-dom/code/934/) on a system that uses PHP to generate classes for C++ that act as heterogeneous containers for XML Schema described XML documents, etc.

There's a weird irony in using weak-typed PHP to develop strong-typed tools for C++, but it works because the PHP code runs one-time, offline, which is where PHP makes the most sense I suppose, performance characteristics be-damned. And the schema is so huge/labyrinthine that you need something like C++ to approach it, or else you may find yourself stuck in its labyrinth forever.

https://www.khronos.org/collada/wiki/ColladaDOM_3 https://sourceforge.net/p/collada-dom/code/HEAD/tree/trunk/dom/include/3/COLLADA%201.5.0/COLLADA.h https://sourceforge.net/p/collada-dom/discussion/531263/thread/6445b0224b/

[Ryochan7]

ElementAt was primarily used when iterating over some Dictionary objects as an alternative to using foreach. I don't know about it affecting the memory footprint but using ElementAt is supposed to be inherently slow. Unless a data structure is already indexed, such as a List, ElementAt could potentially walk the entire data collection until it reaches the item at the requested index. Given that ElementAt was being used in at least two places in one gamepad poll, using it could have a major impact depending on the number of items stored. It was a mistake to use that approach.

I have not used PHP in years but PHP was a decent language to work with. I never used it for making any desktop related applications. Writing PHP code to generate C++ classes is pretty interesting.

[m-7761]

(Usually a container that can't efficiently implement "ElementAt" would not provide that as an option. I kind of assumed it was a standard container. But I don't know what's what when it comes to C#.)

That project is (unfortunately) still a little bit futuristic. Visual Studio (which blows all the competition out of the water) can't build it fast enough, even with making it as streamlined as possible. And IntelliSense can't reliably parse it so that the comments appear, and auto-complete works reliably. It's hit or miss for every edition of VS in different ways, and anything before the 2015 edition can't compile C++'s templates fast enough to be of use, and the precompiled-headers tend to be gigabytes big. Which can't be loaded into the address space of 32-bit software, which Visual Studio generally is. Though later editions somehow manage it...

I suspect in the future it will become more common to describe information-fields with things like XML Schema, so that you are not in a situation where your code that describes what to do with your information has to also encapsulate the information itself. That's just sloppy and burdensome. The disciplines are naturally separate, and can How code works is more important than What it works on/with. Usually, today, it's more expedient to mix these things in code, and the tools are not good at teasing them apart. It's not until you come up against something impossible like COLLADA that you see there is no way to sit down and type it all out by hand into your software.

EDITED: Of course! Typing it all out (with strings no less) is exactly what everyone does... or does partly. And unfortunately in the XML world the "SAX" approach dominates everyone's thinking. SAX only works for trivial data, and is a tortured way of working with data that affords no way for anything that looks like an algorithm to enter the picture.

[Ryochan7]

This type of issue has only been resolved fairly recently (2019/10/31). I did not run into problems with unbound memory usage until moving the code base to use WPF. Only then was memory usage mostly unbound and just kept increasing to over 256 MB.

A method of periodic garbage collection was discovered that didn't impede the application so it got included in the WPF build and the Windows Forms build. It was introduced in version 1.7.21. This type of issue could have been solved sooner if I had run across it on my rig earlier.

https://github.com/Ryochan7/DS4Windows/issues/866