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]

I don't see a version on mine (it wants to update to 1.5.8) but... I'm watching its memory use go up 1MB every second. Can anyone recommend a version?

[jonaaa20]

Honestly I don't have any problems with memory leak, i have tested on RetroArch and Rocket League, you guys are using 1803 of windows 10 right? I don't know if that's the reason but I'm using the 1607 and I don't have problems with memory...

[m-7761]

Open Task Manager and see if the memory keeps going up. Memory leaks aren't because of OS build numbers.

BTW: I cannot find the version in the UI. So, that's another problem that could be addressed at the same time.

I think if lediafru saw 7.3GB they probably had it running for about 2hrs. If not, the leak is variable. It's unlikely exactly 1MB/s, but that's about right. EDITED: I'm not sure how many GBs 64-bit processes are allowed have, but that's probably getting close to the limit. 32-bit is limited to ~2GB.

[Ryusennin]

The version number is indicated in the log tab and when hovering the mouse over the systray icon.

I'm on Win7-64 and haven't noticed any memory leak for months. The process currently sits at around 30 MB.

[BlackPowerade]

Win10 1807 here. Had DS4windows running for about 6 hours now, process is sitting at about 50 MB right now. Version is 1.5.8

[m-7761]

Well, you guys are lucky then. Glad I can confirm the leak. I didn't see a version in the systray. I'm sure I looked there.

For me it's a little inconvenient to be of help, because I'm using DS4Windows's SCP-bus to make ScpToolkit work, but if I run DS4Windows and stop or close it, ScpToolkit stops functioning until reboot. I've been trying it with a DS4 lately also, but I can just add that i'm seeing a leak, with BlueTooth mode. Probably with USB also, when plugged in. But yeah, turn it on and it starts leaking/doesn't let up for a second.

EDITED: It's unlikely the OS, etc. matters. It's probably some setting that is different. I wish I fiddle around but I hope some else will. Any allocations that happen on a real-time basis are suspect.... that's rare with C++ applications, but C# may be one of those things that's always allocating dynamic memory for every little thing it does.

[Ryochan7]

Been busy for the past week re-learning Django. The only time that memory would possibly leak is if the ClearSentData event handler is not called after sending the data. Although I tested it on my system and the scenario didn't occur for me, there is a scenario when the applicable event handler will not be called so the data will not get disposed. That would cause a memory leak. Quitting the UDP server would be required to free that memory. I am guessing that is probably what is happening for some people.

Instead of creating new object instances when new data is sent, I should probably set up some type of pool and re-use objects instead.

[m-7761]

@Ryochan7 FWIW I don't have the UDP server option turned on. (Maybe that's a broadcast option, but can't hurt to share.) Windows 10. EDITED: I have ScpToolkit running, just FYI, in case there is possibly a conflict.

[javsp]

I can confirm the leak as well, not only the latest version (1.5.8) but also older versions. I'm now using 1.4.121 which has motion control support in Cemu and it seems the memory doesn't keep going up (or if it does it slowly raises). With this version the RAM usage is about 11-12 MB. With the latest version it uses +50 MB after restarting the app (or Windows reboot) and waiting a couple of minutes. Imagine after a couple of hours. No matter if DS4 is turned on or not.

I have W10 (latest build) and I'm using the x64 version of this app.

[m-7761]

Any progress on this existential crisis level bug?

[Ryochan7]

Not really. There is a workaround for the UDP server memory leak in the current code but you mentioned that you have the server disabled in your config. I have not encountered a memory leak in any other portion of the program that I have tested.

I have not touched the DS4Windows code in the past couple of weeks. My coding time has been spent working on a small video hosting site similar to what was available on PewTube. Re-learning Django again has been interesting although figuring out how to express more complex types of queries using the Django ORM has been a challenge. You can check out what I have been playing with if you are curious.

http://ryochan7.xyz:8000/

I need to play around with DS4Windows a little bit over the weekend at least. A new binary build should probably be pushed out with the workaround as well. Another task would be to finally review a pull request that was submitted a while ago.

[keatsandyeats]

I just upgraded from 1.5 to 1.5.8 and encountered this memory issue as well. The program starts with about 20MB used, then increases by about 100kB or 200kB every second. Occasionally the memory increase pauses for a few seconds, then resumes again. I watched it go up to 80MB, then I got bored and stopped the process manually.

I checked some other versions: the issue does not occur in 1.5 or 1.5.6, but does occur in 1.5.7 and 1.5.8. All versions I used are x64.

I did not previously have the UDP server activated. With the UDP server active on 1.5.8, the leak seems to increase by about an extra 100kB/s. I am on Windows 10 1703 x64. I don't use HIDGuardian or any similar program, just DS4Windows. I have one controller, plugged in with USB. I don't use bluetooth.

[javsp]

I've found something interesting: if I remove the file "DS4Windows.exe.config" from the DS4Windows folder the leak does not happen in the latest version. However, if I do that the program runs always in English (it ignores the selected language pack). I'm fine with that but I don't know if it breaks something else. As I said in my other post I have to use 1.4.121 (maybe 1.4.x) in order to avoid the memory leak if "DS4Windows.exe.config" it's not removed from the folder.

Does it make any sense for you?

[m-7761]

Again, I see approximately 1MB/s. Mine might be higher because I had increased the polling rate, after searching for solutions for frequent latency drops (flashes) ... speaking of which, the default polling rate should be increased to much higher. There's no reason to make anyone have to search for solutions to the latency hiccups/flashing lights, if there is a straightforward fix. (It could even be bumped up in a response to hiccups if there is some good reason for leaving it at a more conservative setting.)

It makes sense that the leak is proportionate to polling events, unless there are other activities that happen on a real-time basis.

[Ryochan7]

The setting in the DS4Windows.exe.config file should not lead to a memory leak. The relevant tag is as follows:

<gcServer enabled="true" />

That tag enables server mode for the garbage collector rather than using the default workstation mode. Enabling that setting is probably more appropriate for running ASP.NET sites but I find input latency is better when the garbage collector is run less frequently. Granted, that setting will cause the program to use more memory than if workstation mode were being used. On my system, memory usage maxes out at around 60 MB and gets dropped to around 40 MB shortly after. The benefit of enabling that setting outweighs the cost on my system. I would not want to change the setting back unless it was truly deemed necessary.

The optimal Bluetooth polling rate is dependent on many factors with the biggest one being your Bluetooth dongle. 4 ms has been fine on my system and it causes fewer issues with ScpVBus than if the fastest poll rate were used. The Linux kernel module hid-sony also uses 4 ms as the default Bluetooth polling rate for DS4 controllers. I would not want to try to implement some kind of dynamic poll rate changer which would cause more work for the program and add additional latency for probably not much of a benefit.

[Ryochan7]

I have tried changing the gcServer setting back to false. Input latency is definitely worse but memory usage stays around 12 MB. Also, GUI responsiveness is worse when server mode garbage collection is disabled.

As far as I know, the amount of memory used for server mode garbage collection is determine by the .NET Runtime based on how many CPU cores your system has; for the record, my system's CPU has 6 cores. I cannot find a setting that can be used to create some kind of memory cap. For me, reducing input latency is far more important than reducing memory usage.

[m-7761]

Off-topic: Maybe the latency issues have to do with process priorities... is DS4Windows registered as a real-time multimedia process? And if not, what happens when other such processes (e.g. games) are active? I can't really speak to .NET, but if this garbage-collector is built-in and so unavoidable, it can only at most be the straw the breaks the proverbial camel's back.

[Ryochan7]

The program is set as a high priority process. I tried the real-time priority setting and I found the output controls to be a tad wonky in game (Gex).

The garbage collector is a standard part of the .NET Runtime that is unavoidable. Low latency mode was being used in workstation mode for minimizing the impact of the garbage collector on the application. The garbage collector can be manually invoked periodically and that can minimize memory usage in server mode. However, doing that pretty much negates the performance improvement from using server mode.

[m-7761]

FWIW I know .NET is a different beast from Win32, however I learned only relatively recently myself that the SetThreadPriority API seems to accomplish almost nothing nowadays, and that the real APIs for process priority that games use is AvSetMmMaxThreadCharacteristics and friends. Probably if .NET has an API it's this, but just thought it can't hurt to share. The name of these APIs are far from obvious ones.

[m-7761]

I found that after prolonged play the leaking behavior will eventually plateau on my system, and has never exceeded around 400MB. It usually stops around 290MB, and may occasionally ratchet up. I could not see any rhyme or reason to it. Just, as I watched it, it would eventually stop going up, and just sit there.

It almost seemed like on two occasions it stopped after I happened to put the controller down, and pick it back up (stop inputting) but it could be I lost track of time, so the longer the wait, the more time there is to stop.

I am doing tests with the DS4, and today got some mail order accessories to try to make it easier for me to use. Which is why I had it out. I had to increase the poll rate again, all the way to Max to make BT to work reliably. It seems like there must be something to that. Increasing it before helped, but today the connection was just unusable until ramping up even further.

The DS4 has really high tension, compared to a SIXAXIS I prefer (I much prefer its light weight if nothing else) that I'm praying is just new controller stiffness. It feels like rumble when a stick is pulled back and let go. I don't know why it's designed like this. It makes cinematic camerawork impossible...

Off-topic: I say so, because I cannot shake the sense that the DirectInput device in my software is not updating itself at the same rate as the BT poll. The display in DS4Windows looks responsive/continuous, but the client software feels very stop-and-go, and not like the SIXAXIS with ScpToolkit. I have so far been unable to use the DS4 with ScpToolkit, even though I'm pretty sure it's in the list of controllers it works with... I will make a point to redouble my effort. (ScpToolkit doesn't even work since a couple months back unless DS4Windows is installed with its ScpBus component. I'm praying yours keeps chugging along in the meantime.)

[Ryochan7]

It really seems like I have been running into fundamental issues with .NET that cannot be worked around. It sometimes makes me think about going back to using C++ and Qt more often. C# is a pretty neat language though and the .NET Runtime is definitely better than the Java Virtual Machine.

[m-7761]

@Ryochan7 I don't know. I have been considering using .NET for the first time myself. The PSVRToolbox code uses C# to get polling data from the PSVR that seems really reliable. I think it sends 2 samples in each USB datagram, but its sensors update at very high frequencies... 2000/s I think. If there are timing issues, I think there must be workarounds or other causes. Maybe the PSVRToolbox codes does things in a special way, or maybe it registers its process as an Multimedia Input process with the scheduler. I think if DS4Windows is not registered with the scheduler that can only be bad. The Win32 way to register with the scheduler is AvSetMmMaxThreadCharacteristics. Input is one of the special groups that are available.

[Ryochan7]

So much time seems to be spent just trying to get .NET to behave the way I want. It has also impeded implementing features on several occasions. The most recent example is when adding a reference to an assembly (System.Numerics.Vectors) killed the performance of DS4Windows and a smaller DS4 controller emulation program. The idea of implementing a square stick routine that people had requested was scrapped.

I wrote a small controller emulation program in C++ a long time ago and I still tinker with it on occasion. Even though the C++ program is a bit more responsive, the difference seems fairly minor. It would be nice to not have to spend several hours testing minor code changes to try to get performance to meet my expectations.

https://bitbucket.org/Ryochan7/xinput_scpcontrol_test/src

[m-7761]

I don't think System.Numerics.Vectors is a problem. I've never had to figure out "profiling" but it seems like there is a problem that interacts in strange ways. A bug in a system can exhibit very bizarre behavior that can seem to be unconnected to anything else. Sometimes it's like worms eating tunnels through an apple. I don't know if C# changes that dynamic, but it's very common for code that can modify memory freely.

I have the opposite problem to #341 since my software's code (https://www.reddit.com/r/KingsField/comments/9kj984/very_early_playable_section_of_kf2_for_windows/) just this year began to grapple with the paired axes being almost square instead of a circle, and so I was able to eventually greatly improve the input for SIXAXIS and I believe most joysticks of yore, that are as far back as I can remember, square, only to discover that the DS4 reports via DirectInput an already circle shaped relationship between its axes, which I'm guessing is common with newer controllers, based on the X-Box's model, so until I can find time to set up an elaborate configuration system, I've had to reduce the mapping from square to circle as a kind of middle compromise.

For me software has always been time-consuming, and thankless, so it would not deter me at all if I was faced with a misbehaving program. I encourage you to stay with it. I'm considering myself, including custom DS4 code in my own work, but without plans to run it through XInput as DS4Windows does... just instead to provide it alongside direct support for other PlayStation peripherals. I so far much prefer the SIXAXIS, but from what I can see, it is not practical for Windows. (Others are pursuing it anyway, but the PS3 controllers will eventually wear out no matter what develops.)

P.S. xinput_scpcontrol_test converts DirectInput to XInput? I always thought controllers were DirectInput or XInput, and that if the latter, XInput automatically facilitates a DirectInput version of that controller. Never mind, not worth discussing. I have a palm sized workstation that is i5 with Intel Iris Pro graphics, so I wonder if I'm seeing scheduling issues between all of these components that "gamers" with hot-rod desktops don't feel. If the XInput state (and therefor DirectInput's) is not updating at 60fps or so, steadily, then it has to be because of scheduling conflicts, and I think that the workstation has more than enough power to spare, but only if all of the components are on the same level priority wise. I'm guessing ScpBus generates the XI device, and DS4Windows feeds the bus. I just get the feeling that the DS4 via DS4Windows is choppy, whereas DS3 via ScpToolkit feels correct. It could just be that it is applying a filter. But it feels more like polling is returning a stale state. I worry I'm not contributing anything of value to this conversation, so I want to just leave it at that :)

[m-7761]

P.P.S. Your video project (are you hosting bandwidth too?) introduced me to TempleOS, so thanks for that ;)

[Ryochan7]

The program originally used SDL to read controllers. The program would only work with controllers with a specific GUID. SDL would read the controller state from the DirectInput devices. ScpVBus would be used to create the XInput controller.

The program was changed to behave more like DS4Windows and read from the HID device instead. That program has the main mapping features that I use with the exception of stick coordinate rotation. Techniques discovered while coding DS4Windows have been incorporated into the program.

It is a bloody shame what happened to Terry. I liked watching his sermons and he did some really cool things with TempleOS. I haven't visited the temple in a while but I still have a VM with TempleOS on it.

On Thu, Oct 11, 2018, 8:46 PM Mick Pearson notifications@github.com wrote:

P.P.S. Your video project (are you hosting bandwidth too?) introduced me to TempleOS, so thanks for that ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/418#issuecomment-429176573, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjhUONsTM0gD-ZlHfbtUIMzBwbOaiMzks5uj_SBgaJpZM4WgDXV .

[Ryochan7]

ScpVBus does seem to have a buffering problem in some circumstances. That is especially evident if you try to use the max BT poll rate available. Reducing the poll rate to 4 ms actually reduces input latency in that case. There are other problems presented by DS4Windows itself but I try my best to get performance in line on my machine anyway. Honestly, using updated ViGEm support gets rid of the problem somewhat although you would have to not use the stable driver and build ViGEmBus yourself.

When I tried ScpToolkit, I found it to be the worst option for DS4 support. Despite being a driver, it actually presented the most input lag of any option available. Last I knew, FireShock did not have proper DS4 support yet so I cannot test it out to see how performance has changed since ScpToolkit. I do not have a DS3 controller in my collection.

I have a more minimal code base on my machine with the DS4Control and DS4Forms packages stripped but some changes proposed for DS4Windows still caused problems in that program as well. It seems like a code refactor might not even make things easier.

[m-7761]

Okay, I appreciate that I might be in a catch-22 with BT versus ScpBus. I think I'm going to carve out an afternoon to add support for the native DirectInput device to my software (add detection code/fake a more conventional mapping of its axes/triggers) and even though off-topic, I'll likely report on how it compares to DS4Windows over BT. It's funny Sony chose to support the older, virtually defunct DirectInput API but not XInput! I can see the use case for xinput_scpcontrol_test now... honestly I don't know what I was thinking before, I'm sure there many games don't work with DirectInput. Despite working full-time on games-adjacent software for Windows I don't have much of a personal history of playing games on Windows (not even a Steam account.)

[m-7761]

Following up, FWIW I don't require sample rates higher than 60fps, however on my system, the BT freezes up unless it's set to the highest setting. In that case, it's just priming the pump, and ScpBus would not have to be updated at the same rate. It's a hack fix IOW.

P.S. Earlier today I did set up Sony's DirectInput drivers, and over BT I didn't notice anything that felt like dropped/stale frames. It's probably the problem you mentioned of ScpBus.

[m-7761]

Triple-post! Funny thing, today I was going to try DS4Windows with 16ms or something more than 4ms. But I've noticed (other than a flash of red just now while I'm typing/not playing a game or anything) that it seems to be working correctly now responsiveness wise at 4ms.

I'm wondering if this is because I used Sony's Wireless Controller with BT for the first time yesterday. I think that it's probably always in use when DS4Windows is working in BT mode, simultaneously, however the only difference is I used it without having DS4Windows running. Sounds like hocus pocus.

Anyway, it's working (for now) except today I also had a scare, because the Xbox Controller did not appear in the Control Panel, not for ScpToolkit either, or DS4Windows. I played with killing ScpToolkit's service, and restarting them, until it worked, and it was back to normal after rebooting, but it was very weird. DS4Windows had a message about the controller failing. Another oddity, is the Use Dinput Only setting was checked. I also enabled the Flush HID setting, which might have something to do with the better behavior, but I don't think so... but weirder still, it is now disabled after reboot.

[Ryochan7]

I don't use the Flush HID setting on any of my profiles and it mainly serves as a compatibility option for older profiles; that option is disabled by default for new profiles because I find that the option can increase input latency and drop some input state changes. I use the Use DInput Only option on the KB+M driven profiles that I use for some games. I have not encountered a problem with DS4Windows ignoring the Use DInput Only option when enabled in a profile.

As it is now, DS4Windows will connect to ScpVBus at app startup but only request for a virtual Xbox 360 controller when a DS4 is detected. Most newer applications should not have a problem with that kind of behavior. Older DirectInput only games would have a problem since most, that I know of, don't have support for hotplugging devices.

I am not sure what the problem would have been if a reboot helped. It might have something to do with ScpVBus. You might have been able to disable and re-enable the Scp Virtual Bus Driver in Device Manager instead of rebooting to work around that problem. You can give that a try if the issue happens in the future. Being tied to an unsupported driver does not help matters. Unfortunately, the ViGEmBus driver has not served as a suitable replacement after almost a year.

[m-7761]

Not wanting to carry on :) just FYI I only mentioned reboot because I was worried that things would revert to not working on reboot. I realize everything about having the controller connected. ScpToolkit is the same way actually (I did remove a paragraph about this, and older software perhaps as you say, only because I thought it was not germane.)

Something odd did happen. No idea what. And it's very odd that I'm not experiencing issues any longer, other than the memory leak. It could be one of those things, like almost all users first use Sony's BT implementation (which might register some things with the system) and so never notice that it's possibly important to getting DS4Windows to work optimally with BT.

P.S. I was curious about longer TempleOS videos but had to wait until I could watch them without cutting into my data-plan. (Satellite Internet.) This one (http://ryochan7.xyz:8000/tag/terryadavis) in particular looks like Daniel Day-Lewis has found a new obscure role. Looks just like Phantom Thread.

[Ryochan7]

It would be weird if that would matter. I don't know if any recent changes made to DS4Windows would have helped on your machine. They seem to help a bit on my machine. DS4Windows does seem to take fewer system resources now as Steam seems more responsive while running the latest DS4Windows.

There are some archive.org listings for a lot of Terry's videos. It looks like this is a more definitive source especially for his more recent content.

https://ia800600.us.archive.org/31/items/TerryADavis_TempleOS_Archive/videos/

[Ryochan7]

The last release and the upcoming release are pretty much just markers for performance changes over time. A lot of releases of DS4Windows that I have pushed out have been like that. Pushing out new features has not been a priority for a while as trying to improve base output performance has been holding back any chance for potential mapping changes. The only major change from recent releases, especially the next release, is that mixed controls (XInput + Mouse aim) is now a lot better and now almost matches what I could perform with antimicro back when I was working on that project. Only delta acceleration is missing and I had tried implementing it before without any success; it was another case of application performance killing any chance of including a feature.

One thing that could really help with my minor case of burnout is to finally get back to my backlog and use changes that I have worked on.

https://backloggery.com/ryochan7

[m-7761]

It's never occurred to me that input devices could ever be a bottleneck, or might under-perform. I hope you are going to take a look at this memory leak. Maybe it plateaus at hundreds of megabytes, but it must be an indication of something, something which could be leaching from your performance expectations. Good luck!

I have not played many games in many years. The medium doesn't exactly appeal to me ever since it moved from its early commercial days to financialization vs. derivative/underdeveloped independent works. But that's fine, since it would be hard to follow video games while doing development as well. (Its audience grew up, but it did not grow with them, and now caters only to an emotionally/intellectually stunted--and increasingly bourgeois--minority. Shame. I don't even know if it's serving the needs of children or not any longer.)

[Ryochan7]

Sometimes it just seems random what is causing a bottleneck. Performance analysis tools in VS only help a little bit for finding bottlenecks; praying to the Nine Divines would be just as helpful. I have implemented some changes that actually made sense but even small GUI changes can drastically change performance.

After the most recent folly, a rewrite is needed. I might play around with .NET more (WPF GUI) but I am convinced that conserving memory and keeping performance in line would require ditching the .NET Runtime. Time to take Terry's advice and write in C.

https://youtube.com/watch?v=bwQl73KgS1g

I don't play that many newer games. Most games that I would care to play would be games that I missed out on during my childhood. Some examples would be the original .hack series and Ocarina of Time.

On Oct 20, 2018 10:11 PM, "Mick Pearson" notifications@github.com wrote:

It's never occurred to me that input devices could ever be a bottleneck, or might under-perform. I hope you are going to take a look at this memory leak. Maybe it plateaus at hundreds of megabytes, but it must be an indication of something, something which could be leaching from your performance expectations. Good luck!

I have not played many games in many years. The medium doesn't exactly appeal to me ever since it moved from its early commercial days to financialization vs. derivative/underdeveloped independent works. But that's fine, since it would be hard to follow video games while doing development as well. Its audience grew up, but it did not grow with them, and now caters only to the emotionally/intellectually stunted.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/418#issuecomment-431635279, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjhUB6-5rR0ynJLDAcRhO2h8D4N4pLiks5um-X5gaJpZM4WgDXV .

[Ryochan7]

It looks like the main problem is due to a couple of allocations performed in Mapping.MapCustom every frame. It is short lived data so it will be discarded when the garbage collector finally gets around to freeing that memory. With the current infrastructure, the allocations have to happen for each frame. Even moving those allocations to static data won't help because output performance gets worse.

[m-7761]

(I'm the same... I still discover games I missed, like Grandia now and then. A game came out like last night called Return of the Obra Dinn that is probably an anomaly, but looks like the effort of an artist interested in the physicality of their adopted medium. That Dragon Cancer looks impressive to me. They have more of the qualities of celebrated adult-contemporary works. --the trouble with video-games is the medium's strength is abstraction. With earlier hardware abstraction is the only path available, but as the other path opened/widened that path is increasingly taken, that is the weak path. Music's strength is abstraction, more-so than video-games'. What if our idea of music was listening to the sound of a street outside our door? That would be a very impoverished pastime. But this is what video-games have become.)

[diogocalgaro]

Just to add that it is also happening to me. I'm using 1.5.14 and it starts at 21mb of RAM and increases 200kb every second. Deleting "DS4Windows.exe.config" seens to fix it.

Win 1607

[m-7761]

DELETING COMMENT: I posted that <gcServer enabled="false" /> did not fix the leak, problem, but it actually does! (I just managed to somehow edit the Copy of the config file I made, instead of the file itself. I caught it when going back to check if I undid the change or not.)

Sorry! I also mentioned in the same post, that I'm having a problem with the Use DInput Only option, always setting itself. That problem is real, and I will make a separate Issue report for it.

FWIW with the alternative memory model, on my system, the memory climbs for a while in real time, but then cuts back to half its peak size around 13MB and stays stable after that. 13MB is a much better footprint than 400MB or so. Are there more settings to configure the server memory model?

SORRY FOR THE CONFUSION (AGAIN)

[Ryochan7]

The only other majorly relevant configuration option for the garbage collector would be gcConcurrent. DS4Windows uses the default value of true which makes garbage collection happen in a dedicated thread. I have tested disabling the option and performance was worse as would be expected.

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcconcurrent-element

Memory usage can be different depending on how much free memory your system has. My system has a total of 8 GB of RAM. On my system, DS4Windows memory usage peaks in the 60 MB range before dropping down to the 20 MB range. Getting axis mapping working without using the dictionary that is allocated every gamepad poll would reduce the rise in memory usage but I don't see a good way around that problem now.

[m-7761]

FWIW my memory is 8GB also. Instantiating dynamic objects every poll is pretty gross hygiene. EDITED: I think it is just a memory model thing. The behavior is the same. One model just assumes it's working with hundreds of MBs instead of 10s.

[Ryochan7]

Luckily it is just one Dictionary that gets minor use as opposed to allocating a bunch of List objects every gamepad poll like the old Jays2Kings code base.

https://github.com/Jays2Kings/DS4Windows/blob/jay/DS4Windows/DS4Control/Mapping.cs#L602

[Mawkey]

Hello, just wanted to comment that I experience this memory leak as well. I am playing on Cemu using UDP server for the gyro. Version 1.5.3.

[mika-n]

I recommend to update to the latest 1.5.19. version because there has been some changes in how UDP and certain list objects are handled in DS4Win. https://github.com/Ryochan7/DS4Windows/releases

[Mawkey]

I recommend to update to the latest 1.5.19. version because there has been some changes in how UDP and certain list objects are handled in DS4Win. https://github.com/Ryochan7/DS4Windows/releases

I tried to do this, but I still have a memory leak sadly. The leak starts the moment I turn on my controller. I also tried to turn off UDP server but it didn't change anything.

https://puu.sh/CjyQU/7f0aeacaf6.mp4 here is a video showing it, not that it will really help, but at least you know I am not lying. This memory leak didn't exist for me when I used the really old version from Jay2King, so it must be something after that.

Edit 999+: Actually seems like it plateaus at 121.2 MB and then it goes back down. Seems like it is fixed, will continue to play and see if it stays this way for longer periods!

[Ryochan7]

There were a few actual memory leaks regarding the UDP server several versions back. The rise in memory usage being documented here is likely due to using server mode garbage collection in the .NET Runtime. With that mode, garbage collection is performed much less often so the application will naturally use more system memory than if standard workstation garbage collection were being used. There is a decent difference in output performance between the two modes so server garbage collection has continued to be used.

The amount of memory that .NET will end up using will vary by system and available system resources. Work will be done to perform less memory allocation in the future to decrease the rise in memory usage. There are a couple of routines in the current code base where memory allocation per gamepad poll cannot be avoided.

On my system, memory usage peaks around 70 MB and goes back down to around 25 MB shortly after. InputMapper 1.7 uses more memory at launch than what DS4Windows peaks at on my system; IM 1.7 uses around 85 MB on my system. I am personally fine with the current memory footprint of DS4Windows.

[Ryochan7]

Commit dd96beafbe2ff8849318acc18a5be409d9b36454 finally removes the allocation of a new dictionary object every gamepad poll. It also allowed me to remove some redundant code in the mapping routine.

[Ryochan7]

I honestly don't know why but version 1.6.11 uses less memory and maxes out at a lower memory footprint than previous versions of DS4Windows. Memory usage seems to max out on my system at around 50 MB now. The performance profiler in VS also shows that fewer objects are created as the program is run compared to version 1.6.10 and the rate of created objects has decreased. I have done some testing and it seems like commit cd6742cf56142639b4182707e586652cd04d34d4 is the magic commit when the memory footprint starts to decrease.

[m-7761]

ElementAt(i) probably constructs an index (unless the container is already an index) but it would unlikely explain memory footprint differences. It may also be copying the container... depending on how C# works... that I don't know. If ElementAt(i) walked the container it would be bad design to provide it in the first place.

It's probably just a "straw that broke the camel's back" thing. But I've learned enough about C# from observing this and other code bases to realize I don't want to use it. Even if C++ is tortured/time-devouring, I think C# must have a lot of problems of its own, that would be more frustrating for a C/C++ developer to adjust to. PHP is probably a lot like C#. I like PHP, but I think it must have horrible performance characteristics, and therefor is not exactly what you'd want to have running on a server every time an HTTP request goes off. But it might have some way of caching itself that makes it manageable. I bet servers are just really inefficient though too.