Performance Advice
Hello there! I'm currently developing some software for a certain company so I can't share that many details, however, I'd still appreciate if some people helped me thinking about a solution for this:
I have two programs, the main one and a secondary one, both written in C#. The main one is x64 whilst the secondary one is x86 due to internal dependencies written in C and compiled for x86. The only way I've found to connect these two are for both of them to be compiled and for a new
Process to be called with command line arguments asking for responses on the x86 program.
This happens every time an action is performed in the x64 program, and it ends up delaying it for a second or so. This is not a big deal for the end-users (It's an internal tool and the maintenance team, which this is designed for, has expressed satisfaction with how it's coming along) but it makes a difference to me. I'm quite perfectionist when it comes to most things.
I have tested everything modularly and the operation that takes the most time, as expected, is the process being started. I have complete access to the code of the x86 program, as I'm the one that wrote it too.
My objective is to cut down on the time it takes for this action to be completed, and it seems like the issue is Process.Start. My intuitive solution is to implement a loop on the x86 that keeps it running and accepting commands and giving outputs, but that will take a lot of processing power due to what it is doing, so I'd like to keep it as a last resort.
Does anyone have any different ideas? Any inputs/knowledge/advice is appreciated! I don't know everything so I've probably missed something.
Thanks in advance!10 Replies
Note: Asking for an x64 build of the dependencies is not feasible, unfortunately. It would take many, many months due to this being something critical, and it would overload the already busy development and QA teams 😛
there are some things that you can do, simplest i guess would be the loop as you said
why do you say that it would take "processing power"? it should take none
either you make it via socket or other ipc mechanisms, or even global mutexes
because other solutions could be even worse, for example keeping a pool of processes in suspended state to be consumed when an input for them is sent
The dependency was made by someone a long time ago, and it's maintained by a few people on the development team. Unfortunately, the guy that initially made it did not document a very specific part of it and due to a few questionable choices it ends up taking up quite a bit of resources on the implementation which I'd like to avoid. I'm trying to keep the dependency usage to a minimum because of it.
Actually I just got an idea... I'll be back in a minute
Okay, I've just managed to reduce said resource usage to practically none
was the idea using the diagnostic profiler?
Only for confirmation on my theory;
There was something that supposedly needed to run every 250ms to ensure things were processed, but it didn't make sense to me and I questioned it; I looked into the code and changed some things in mine and now it only runs once
Thinking back it was pretty stupid
Either way, would the loop be the best option then?
this is still pretty vague, we dont know the size of objects being exchanged and other dynamics, but sure reading/waiting a
Stream (or pipeline, even) would be the classic choicethis is still pretty vagueYeah, unfortunately I have to keep it like this, but you're helping a lot even then ^^ For sure, then I'll be setting up a NamedPipe for continuous IO
i meant
System.IO.PipesYes, I thought of using
System.IO.Pipes.NamedPipeServerStream so I can define a name to the pipe and connect to it through the x64 application. Is that not the best approach?
Actually it isn't, you were right on calling me out... Since I'll be starting the process myself I can just use a normal pipe
My intuititon sent me directly to NamedPipes because previously I've needed to connect through the parent process to the child one, that could be running indefinitely and needed command inputs. It's not needed in this case since the child process will only be needed as long as the parent one exists.if there no redundancy needed, or yes the secondary process doesn't really make sense without the primary then sure