TIL that a trivial Python3 OpenCV program (open an image, attempt to display it in a window) on a Raspberry Pi tries to open over 2800 shared libraries
(EDIT: more like nearly 1400, 'cos strace opens the symbolic link and the library ... but still)
[#]python #OpenCV #strace #RaspberryPi #NotLookingForAdvice
=> More informations about this toot | More toots from scruss@xoxo.zone
@scruss any feeling for what the biggest shared libraries are and how long the long tail of small ones is?
=> More informations about this toot | More toots from mmcknett@hachyderm.io
@mmcknett it's loading a total of 1.1 GB of libraries, with the largest being libLLVM at 111 MB. It seems to be loading libraries for everything, including ones for 3d graphics hardware my Raspberry Pi doesn't have
=> More informations about this toot | More toots from scruss@xoxo.zone
@scruss Erk!
That's one of the common problems of folks misusing libraries: either the program is slow because it's huge, or it's slow because it ld_opens far too many libraries.
=> More informations about this toot | More toots from davecb@hachyderm.io
@davecb it's what OpenCV does. Even on a really fast machine, it takes a few seconds for the Python library to load everything up
=> More informations about this toot | More toots from scruss@xoxo.zone
@scruss
I was in the linkers and libraries team at Sun, and My Smarter Colleagues had carefully collected functions into libraries by the degree of coupling.
Once you'd started a few programs, you probably had most of the set in memory, and dlopen just returned an address mapping. (dlopen not ld_open, I was thinking about ld_preload (:-()
Only when you started something new did the linker drag the thing in from disk and set up swap (paging) space.
=> More informations about this toot | More toots from davecb@hachyderm.io
@davecb no-one should be thinking about ld_preload ...
=> More informations about this toot | More toots from scruss@xoxo.zone This content has been proxied by September (3851b).Proxy Information
text/gemini