Does it go down if you wait for a while? The first import may be searching for fonts which can take a while.

Were you running this test on the original raspberry pi?

Can you also try just running fc-list from the command line?

Now I'm surprised. Thanks for clarifying, I'm curious as to the cause and will check out matplotlib on a comparable computer I have on hand.

also pip freeze would be useful information as I'll try my best to match version numbers.

I ran fc-list, here is the output

pi@raspberrypi:~ $ fc-list
/usr/share/fonts/truetype/droid/DroidSerif-Italic.ttf: Droid Serif:style=Italic
/usr/share/fonts/truetype/droid/DroidSerif-BoldItalic.ttf: Droid Serif:style=Bold Italic
/usr/share/fonts/type1/gsfonts/a010015l.pfb: URW Gothic L:style=Demi
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/type1/gsfonts/n019043l.pfb: Nimbus Sans L:style=Regular Condensed
/usr/share/fonts/truetype/droid/DroidSerif-Regular.ttf: Droid Serif:style=Regular
/usr/share/fonts/truetype/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique
/usr/share/fonts/type1/gsfonts/n019044l.pfb: Nimbus Sans L:style=Bold Condensed
/usr/share/fonts/type1/gsfonts/a010033l.pfb: URW Gothic L:style=Book Oblique
/usr/share/fonts/type1/gsfonts/n021003l.pfb: Nimbus Roman No9 L:style=Regular
/usr/share/fonts/type1/gsfonts/s050000l.pfb: Standard Symbols L:style=Regular
/usr/share/fonts/type1/gsfonts/b018035l.pfb: URW Bookman L:style=Demi Bold Italic
/usr/share/fonts/type1/gsfonts/c059033l.pfb: Century Schoolbook L:style=Italic
/usr/share/fonts/truetype/droid/DroidSansEthiopic-Regular.ttf: Droid Sans Ethiopic:style=Regular
/usr/share/fonts/type1/gsfonts/a010035l.pfb: URW Gothic L:style=Demi Oblique
/usr/share/fonts/truetype/lyx/stmary10.ttf: stmary10:style=Roman
/usr/share/fonts/truetype/droid/DroidSansArabic.ttf: Droid Sans Arabic:style=Regular
/usr/share/fonts/truetype/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic
/usr/share/fonts/truetype/droid/DroidNaskh-Regular.ttf: Droid Arabic Naskh:style=Regular
/usr/share/fonts/truetype/droid/DroidKufi-Regular.ttf: Droid Arabic Kufi:style=Regular
/usr/share/fonts/truetype/droid/DroidSansHebrew-Bold.ttf: Droid Sans Hebrew:style=Bold
/usr/share/fonts/type1/gsfonts/n019023l.pfb: Nimbus Sans L:style=Regular Italic
/usr/share/fonts/type1/gsfonts/b018012l.pfb: URW Bookman L:style=Light
/usr/share/fonts/truetype/lyx/esint10.ttf: esint10:style=regular
/usr/share/fonts/type1/gsfonts/c059016l.pfb: Century Schoolbook L:style=Bold
/usr/share/fonts/type1/gsfonts/n022004l.pfb: Nimbus Mono L:style=Bold
/usr/share/fonts/type1/gsfonts/n019024l.pfb: Nimbus Sans L:style=Bold Italic
/usr/share/fonts/type1/gsfonts/b018032l.pfb: URW Bookman L:style=Light Italic
/usr/share/fonts/type1/gsfonts/p052003l.pfb: URW Palladio L:style=Roman
/usr/share/fonts/truetype/droid/DroidSansEthiopic-Bold.ttf: Droid Sans Ethiopic:style=Bold
/usr/share/fonts/truetype/lyx/cmr10.ttf: cmr10:style=Regular
/usr/share/fonts/truetype/lyx/msam10.ttf: msam10:style=Regular
/usr/share/fonts/truetype/droid/DroidSansGeorgian.ttf: Droid Sans Georgian:style=Regular
/usr/share/fonts/type1/gsfonts/n019004l.pfb: Nimbus Sans L:style=Bold
/usr/share/fonts/type1/gsfonts/b018015l.pfb: URW Bookman L:style=Demi Bold
/usr/share/fonts/type1/gsfonts/n022024l.pfb: Nimbus Mono L:style=Bold Oblique
/usr/share/fonts/type1/gsfonts/c059036l.pfb: Century Schoolbook L:style=Bold Italic
/usr/share/fonts/type1/gsfonts/p052024l.pfb: URW Palladio L:style=Bold Italic
/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book
/usr/share/fonts/truetype/lyx/cmsy10.ttf: cmsy10:style=Regular
/usr/share/fonts/truetype/lyx/cmmi10.ttf: cmmi10:style=Regular
/usr/share/fonts/truetype/dejavu/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique
/usr/share/fonts/type1/gsfonts/n019003l.pfb: Nimbus Sans L:style=Regular

The pip-freeze is here

html5lib==0.999
ino==0.3.6
itsdangerous==0.24
joblib==0.8.3
matplotlib==1.4.2
meld3==1.0.0
mock==1.0.1
msgpack-python==0.4.7
ndg-httpsclient==0.3.2
nose==1.3.4
numexpr==2.4
numpy==1.8.2
oauth==1.0.1
openpyxl==1.7.0
ordereddict==1.1
pandas==0.14.1
picamera==1.12
pyFirmata==1.0.3
pyOpenSSL==0.13.1
pyasn1==0.1.7
pybass==0.55.0
pyfacebook==0.1
pyinotify==0.9.4
pyparsing==2.0.3
pyserial==2.7
python-apt==0.9.3.12
python-dateutil==2.2
pytz==2012c
redis==2.10.5
requests==2.4.3
scipy==0.14.0
simplejson==3.6.5
six==1.8.0
smbus==1.1
statsmodels==0.4.2
supervisor==3.0
tables==3.1.1
tweepy==2.3
twilio==3.6.5
urllib3==1.9.1
wheel==0.24.0
wsgiref==0.1.2
xlrd==0.9.2
xlwt==0.7.5

@alexandruradovici You could run "top" to see which process is taking all the CPU. Then something like "strace -p pid" would show what system calls the process is making.

The python process forks 3 times after import.

The main REPL process stays in read () - as it should be
The other three threads (processes) run gettimeofday

Do you have any ideas about this?

@alexandruradovici honestly, no. I'll try reproducing. It might be worth trying a pip install --upgrade matplotlib as 1.4.2 is a little behind what I've successfully used on the 'pi.

@alexandruradovici depending upon what you're doing, https://pythonhosted.org/pycha/ may work. It's much smaller than mpl.

Okay, finally got around to install matplotlib==1.42 - the first run took ~5.5 seconds, so something is clearly amiss with your test case.

Try pip install --upgrade matplotlib (if you installed via pip)

I installed matplotlib 2.0.0 using

pip install matplotlib

I get the same result using strace.

I am testing using it in a REPL shell. The moment I import matplotlib, the CPU goes up and stays like that

I have the same problem. Did anyone get to the bottom of this one.
Matplotlib 2.0.0, installed via pip3, python3, Rpi3
CPU load goes to 100% for 5-6 seconds, then drops to 75-80%
normal load is 5-7%

Additional information:

python 3.4.3
uname -a =
Linux Antenna_tracker 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux
sample code used to test CPU load

import matplotlib.pyplot as plt

x = [1, 2, 3, 4, 5, 6]
y = [3, 3, 2, 5, 3, 5]
x2 = x
y2 = [3, 4, 5, 6, 3, 2]

plt.plot
plt.plot(x, y,  label =" x y numbers",  color = 'blue')
plt.plot(x, y2,  label =" x2 y2 numbers",  color ='r')
plt.xlabel(" x variables")
plt.ylabel(" y variables")
plt.title('CPU load test plot')
plt.legend()

plt.show()

Similar issue just importing numpy
import numpy as np
makes cpu load go to 300
Both Python2 and Python3 have same issue

I can confirm there are no blatant issues with matplotlib or numpy on ARMv7. I have a full numpy / scipy / matplotlib stack working on armbian working on a 'pi competitor.

Based on the conversation to date it seems most likely that this has nothing to do with matplotlib specifically, so I am closing this.