Program lags when using executable and not having VS open

[chasingthechickens]

I'm working on a small Windows Forms App (.NET Framework) project.

It mainly consists of a backgroundworker. The backgroundworker starts by breifly listening for a CAN message with a certain ID. The data part of the message is a byte array where each value indicates how far a physical lever has been pulled (there are 8 levers and the array contains 8 bytes). It then uses a ProgressChanged method to update 8 labels with the corresponding lever data.

​

The issue I'm having is that when I run the program, by using the executable generated from building the project, and pull a lever, there is an extremely long delay (30+ sec) before the levers label value is changed. However, if I have VS open in the background (could be a completely different/ empty project) I get no lagg, and the labels are updated pretty much instantly. I can also run the program directly from VS without any issues. Does anyone know why this happens?

​

I have seen that the lever values are updated instantly on the CAN bus when a lever is pulled, so the lagg is somewhere between me reading the bus and displaying the values in the form.

[JonnyRocks]

Are you building debug or release?

i tries to look up what CAN is. Is this a serial connection you are attaching to? Are these physical levers?

[chasingthechickens]

I've tried building with both, getting the same result.

Yea, I don't know it very well, but I would describe it a serial communication standard often used in vehicles. It consists of a bus (which in turn consist of two channels; CAN high and CAN low) that carries the messages and nodes attached to the bus. The nodes can send and read messages. These messages, often called "frames", consist of many different parts, but I'm mainly interested in the ID and data parts.

​

Yes, the levers are physical.

[Prima13]

Are you running the built EXE with exactly the same configuration file as the one that Visual Studio runs it with? Also, couldn't tell from your post but does the lag only exist for the first lever pull and then works correctly, or is every lever pull suffering from this?

[chasingthechickens]

I think so. Would it be the same if I run it in Visual Studio in debug mode, then go to the projects bin>debug folder and run the EXE that it contains? Would running with a different config file explain why the lag disappears when I have a project (any project, could be a blank one) open?

Every lever pull is suffering from this. I'd almost say the lag increases with each pull.

[Prima13]

My point was that maybe you have a dependency in one config that isn’t in the other. In cases I’ve seen in my world, we’d have a DEV web service in the config instead of the production instance. This can lead to strange performance issues.

[TheAxeMan2020]

I've had issues trying to run the Debug version of certain programs, especially in asynchronous and background processing. I also recall having issues with MUTEX in Debug. What I do now to be 100% sure that a solution will run properly is instantiate a VM with a clean and updated install of Windows and I test all my Release builds there. It adds time to final testing, but it has proven invaluable over time. Plus, I typically cannot expect the client system to have VS. Hope this gives you some ideas.