Make sure plot does not slow down ipopt about bioptim

[EveCharbie]

Working on it :)

[mickaelbegon]

Is it possible to add this information somewhere that realtime plots may affect speed of about 15%?

[pariterre]

Make sure the communication between the processors are using UDP and not TCP, which could slow things down otherwise

[EveCharbie]

It does slow down IPOPT. I tested with maximize_predicted_height_CoM, results are as follow:

1. Test for t = 5, ns = 200
   With plots : 19.38321542739868 s
   Without plots : 18.32109808921814 s
2. Test for t = 50, ns = 200
   With plots : 342.2361035346985 s
   Without plots : 307.77546977996826 s

I think the problem is at recv : "[recv] Bloque jusqu'à ce que quelque chose soit reçu." https://docs.python.org/fr/3/library/multiprocessing.html

Possible avenues for solution:

1. Treat arg[0] as a socket data flow with recvfrom (class socket) which is the UDP version of recv. https://pythontic.com/socketserver/threadingudpserver/introduction
2. Use multiprocessing.sharedctypes to access shared memory (bypass recv). https://docs.python.org/fr/3/library/multiprocessing.html

[EveCharbie]

I implemented the shared memory option. It still slows down Ipopt :(
Results for 30 trials of maximized_predicted_height_CoM:
with plots : 20.52554191748301 +- 1.12808514596442
without plots : 17.647579884529115 +- 0.39544275397521056

[pariterre]

So it is the same order of magnitude? Could you redo the one which was taking 5 minutes? If it gives the same thing, then I think we can leave it as is (since we will never do faster than shared memory)

[EveCharbie]

maximized_predicted_height_CoM, ns = 200, t = 50:
with graphs results : 323.4463245312373 +- 18.840376615154913
without graphs results : 282.86038216749824 +- 5.873278186064388

[pariterre]

It seems that shared memory or send/recv are equivalent. Since the one already implemented works, I think we will keep it. Thanks for answering this Issue!
GJ :)