Hacker News Reader

Comment by alex_smart | Hacker News Reader

>Nobody does it because it absolutely never works.

As an intern at a data science company, I noticed that a certain closed-source shared library we were using was calling the same trigonometric functions with the same arguments over and again. So, I tried to use LD_PRELOAD to "monkey-patch" libm with caching and that reduced the running time of the data pipeline by 90%.

>I never want to see a dynamic library again.

And replace it with what? Completely statically linked libraries? How much disk space would linux userland require if every binary was to be statically linked?

View on HN

I like the anecdote, but I don't see what argument it offers. Usually, the core maintainers are the one with the strongest context on the project, and thus would have the best knowledge of optimization locations.

Telling maintainers to dynamically link just in case someone wants to change the libraries is like having replaceable CPUs on motherboards. Useful for 0.1%, but requires a lot of working around.

I was just giving a real-world example where dynamic patching via LD_PRELOAD was quite useful, not offering it as an argument for maintainers to use dynamically linked libraries.

Of course, there are many independent arguments for using dynamically linked libraries, which is why most linux distributions use them.

> replaceable CPUs on motherboards

What do you mean by this? You can generally replace the CPU on a desktop or laptop motherboard.

> As an intern at a data science company, I noticed that a certain closed-source shared library we were using was calling the same trigonometric functions with the same arguments over and again. So, I tried to use LD_PRELOAD to "monkey-patch" libm with caching and that reduced the running time of the data pipeline by 90%.

This is a very edgy edge case, though.

> How much disk space would linux userland require if every binary was to be statically linked?

Megabytes more?

I have never been on a project or a machine since the 70s where executables took a majority of the disk space. On this disk, about 15% of it is executables, and I have a lot of crap in my executable directory and just deleted a lot of junk data.

Also, no one's seriously proposing that core libraries that everyone uses be statically linked.

>Megabytes more?

Megabytes more in total, or megabytes more per binary?

> On this disk, about 15% of it is executables, and I have a lot of crap in my executable directory and just deleted a lot of junk data.

Is there any study on how this might change if we moved from dlls to statically linking everything?

> no one's seriously proposing that core libraries that everyone uses be statically linked

If we agree that shared libraries are fine for the common case, and there are n number of existing solutions for distributing applications with tricky dependencies, what are we even talking about in this thread? :\

> Is there any study on how this might change if we moved from dlls to statically linking everything?

Drew Devault did an informal one https://drewdevault.com/dynlib.html

TL;DR - not at all substantially.

The disk space issue could fixed other ways. Have the filesystem automatically find and shared common blocks.

into, say ..... common block libraries?

no, into common block maps. it's filesystem compression and deduplication, and it works great, on a lower level from libraries. I use it with ZFS and btrfs, works wonders.

Reply on news.ycombinator.com