Performance Issue: bcast pickles objects unnecessarily

[Sam Chill]

First I would like to say thanks for making mip4py! Its a fantastic library.

When calling bcast() on a communicator, the obj parameter is always pickled even when the communicator size is 1. When the communicator size is 1, the call to bcast() should just immediately return obj. As it stands now the call may have a lot of overhead due to the call to pickle.

The use case behind this is I have a function that reads data from the file system and broadcasts it to all ranks. This same function is used when running a parallel simulation and when visualizing results in a GUI. The GUI, of course, does not use MPI and needs to read in all the data to create a visualization. The call to pickle can cause huge slow downs, because the object that is being pickled is complex.

The workaround is pretty easy. Only call bcast() when run in parallel, however, I think this is surprising behavior and should be fixed.

[Lisandro Dalcin]

This behavior is actually on purpose, the return of bcast() is always a deep copy of the input object (as with copy.deepcopy()), even at the root process. Implementing your proposal will break that rule for the uni-processor case. Given that many Python objects are mutable, your proposal leads to a backward-incompatible change in behavior that may affect third-party code. Also, others would argue that this optimization should be implemented in the other collective calls, e.g. scatter() or gather(). Finally, the "fix" on user's side is quite trivial, say if comm.size > 1: obj = comm.bcast(obj). After outweighing the pros and cons, I'm afraid I have to reject your proposal.