Matplotlib savefig and close break multiprocessing and numpy thread allocation

[dpjensen]

Bug report

Bug description:

I recently updated my python environment and discovered a weird bug that occurs between matplotlib, numpy, and multiprocessing.

Code to demonstrate the bug below. In the code I am running a multiprocessing pool, with a function that multiplies small matrices a large number of times. If run on its own this fully utilizes the expected number of threads/processes (num_threads). However if a plot is generated and saved before the multiprocessing loop begins, then all of the processing seems to be forced onto only 2 threads.

Time is used only to demonstrate that the code runs much slower when the bug is occurring, on my machine (48 cores/96 threads) it runs about 30 times slower when the bug occurs. The try/except is used just so the pool is closed properly if you keyboard interrupt.

import numpy as np
import multiprocessing as mp
from matplotlib import pyplot as plt
import time

def test_function(var):
    test_mat=np.zeros((3,3))
    for i in range(10**6):
        np.matmul(test_mat,test_mat)
    return()
    
def main():
    print('starting')
    
    test_array=np.arange(10)
    fig=plt.figure()
    plt.plot(test_array,test_array,'.')
    plt.savefig('test_fig.png')
    #plt.close('all')
    #plt.close(fig)
   # plt.close()

    num_threads=mp.cpu_count()//2
    pool=mp.Pool(num_threads)
    
 
    try:
        completed=0
        tic=time.time()
        for item in pool.imap(test_function,range(num_threads*2)):
            completed+=1
            print('%i completed'%(completed))
        
        toc=time.time()-tic
        print('Elapsed time %f seconds'%toc)
        pool.close()
        pool.join()
    except:
        pool.terminate()
        pool.join()
    
if __name__=='__main__':
    main()

This bug also occurs when using plt.close, although I tested a few different versions of matplotlib, and the behavior changes. With python 12 and matplotlib 3.10.0 the bug occurs with plt.close(fig) and plt.close('all'). With matplotlib 3.9.2 and 3.8.0 the bug does not occur with plt.close('all') but still occurs with plt.close(fig). The bug does not occur with a plain plt.close() in my testing.

This bug occurs in an important piece of code I am using at work so I am trying to find a working python environment where it does not occur. It seems like the bug does not occur in python 10, even running the same matplotlib versions listed above, so it seems to be a python bug, not a matplotlib bug. (I was previously working in Python 8, but had to update). Bug appears to be independent of matplotlib backend.

OS RHEL9.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

[gaogaotiantian]

Not able to reproduce this on Python 3.12 + matplotlib == 3.10.0. The elapsed time is stable. The fact that changing matplotlib version affects the result might suggest this is related to matplotlib. To submit an issue with CPython, you should be able to give an example that is independent of 3rd party libraries.

[dpjensen]

Interesting, I am installing from Anaconda so possibly there are other factors. But this issue occurs for every installable version of matplotlib on python 3.12, and no installable version of matplotlib for python 3.10. That suggests the issue is with python (I assume somewhere in the multiprocessing module). As I said, also had this problem on an install of python 3.11, although I didn't test that as thoroughly.

Additional note: This issue doesn't occur if the process pools are spawned instead of forked, so it will only happen by default on Linux, and will not be reproducible on windows. But for my actual working code forking takes less than a second while spawning takes several minutes before processing starts, so switching to spawn is not an acceptable solution.

In case you are running this in ipython, if you save or close a figure and cause the bug, it will persist in the ipython session until you restart the kernel. This is why I did not provide a single script that shows the code with and without the bug, you will need to comment out the savefig and close lines yourself to test. Alternatively I suppose I can make another version where the loop runs once before the figure commands and then again after.

If you watch your cpu usage (I am using htop for that) when the figure commands are commented out you should get half your CPU threads up to about 100%. When the figure commands are put back in only two threads should be at 100% and the rest are very low.

[gaogaotiantian]

I'm testing this on WSL so it's a forked pool. The program takes 2s with or without the plt.close() statement (in all forms). I also tested this on 3.11 and the result is the same. I'm afraid at this point I can't help you. You need someone else that can reproduce this issue. It would be nice if it does not rely on 3rd party libraries. You can try to trace it with viztracer to check if the other processes are indeed idle (and if so, why).

[ZeroIntensity]

Interesting, I am installing from Anaconda so possibly there are other factors. But this issue occurs for every installable version of matplotlib on python 3.12, and no installable version of matplotlib for python 3.10. That suggests the issue is with python (I assume somewhere in the multiprocessing module).

Well, not necessarily. They could be using all sorts of private C APIs that don't work as well under multiprocessing. (I can't think of an example where that would be the case, but my point is that "working in 3.10 but broken in 3.12" isn't always a telltale sign of an upstream problem, especially in these big libraries using all sorts of internal hacks for optimizations.)

I think you should report this to either MPL or NumPy first, and then let them determine if it's an issue on our end. If it is, then they'll typically report this to us with a reproducer using only the standard library. Thanks!