uprocd

uprocd is a "process preloader" or "process cache" for Linux systems. It starts a process (referred to as a module) in the background, then freezes it once initialization is completed. When you ask uprocd to run that module, it forks it and attaches the forked version to your terminal. This means that processes are only initialized once, so you don't have to wait around after starting a process.

In other words: many programs will have a "daemon mode", where a copy of the program is running in the background, in order to improve startup speed. uprocd uses the same principle, except it is designed to be more generic: any application author can easily create a uprocd module in order to make their application's start-up time faster.

Want proof that it works?

# IPython ryan@DevPC-archLX  ~  /usr/bin/time -f 'Time elapsed: %E' ipython -h > /dev/null Time elapsed: 0:00.60 ryan@DevPC-archLX  ~  /usr/bin/time -f 'Time elapsed: %E' u ipython -h > /dev/null Time elapsed: 0:00.15 # Mypy ryan@DevPC-archLX  ~  /usr/bin/time -f 'Time elapsed: %E' mypy -h > /dev/null Time elapsed: 0:00.52 ryan@DevPC-archLX  ~  /usr/bin/time -f 'Time elapsed: %E' umypy -h > /dev/null Time elapsed: 0:00.11

The uprocd version is faster because a copy of IPython was already running. That copy was just forked and attached to the current terminal.

You need:

A C compiler.

Python 3 and Fbuild 0.3 RC2 or greater for building (just use the master branch).

branch). Judy arrays.

A systemd-powered Linux system. uprocd itself only spawns daemons for each module and manages communication with them. systemd is used for both managing the daemons (via systemctl) and internally used for communication (via sd-bus).

Optional: mrkd if you want to build the man pages.

mrkd if you want to build the man pages. Optional: CPython 3 development files if you want to build the Python and IPython modules.

CPython 3 development files if you want to build the Python and IPython modules. Optional: Ruby for building the Ruby module.

Just run:

$ git clone --recursive https://github.com/kirbyfan64/uprocd.git $ fbuild $ sudo fbuild install # Enable the cgrmvd system service. $ systemctl enable cgrmvd $ systemctl start cgrmvd

Use fbuild --release for a release build.

# Start the uprocd Python module. This will start Python in the background, then # freeze it until later. $ systemctl --user start uprocd@python # Have the module be automatically started at every boot. $ systemctl --user enable uprocd@python # Run Python via uprocd. This will fork the background process and bring the forked # one to the foreground. $ uprocctl run python -h # u is a shortcut for uprocctl run $ u python -h # upython is an included shortcut for u python $ upython -h # In fact, any symlink to uprocctl beginning with the letter u is a shortcut. e.g. # a symlink named uipython is a shortcut for uprocctl run ipython: $ uipython # Same as: $ u ipython # Same as: $ uprocctl run ipython

For more information, see the man pages via man uprocd.index , or view them online.

Again, see the man pages for detailed information. If you want to get started, check out the source code for the both the Python modules and two basic examples.

Android's Zygote does something similar to ensure the VM is already warmed up: it loads once, then forks off into other processes with an already-warmed VM.

I was also recently informed that KDE2 did something similar with kdeinit in order to avoid loading shared libraries over and over again.

It shouldn't affect it that much. For instance, leaving uprocd's IPython module running in the background won't affect your memory usage much more than keeping IPython open all the time.

Now in theory, uprocd could actually decrease memory usage: since forks are copy-on-write, any memory that isn't written two would be shared between processes. However, all the current uprocd modules (Python and Ruby) use interpreted, garbage-collected languages, and the second the GC touches a memory page, it will be copied.

If a uprocd module were created for program written in a non-GC'd language, it would be more likely to show decreased memory usage.

Yes. In theory, this isn't much of a loss: systemd's parallelism helps ensure that uprocd alone won't hold back your entire boot, and I personally haven't noticed any significant slowdowns.

That being said, if you want the stats: the Python modules each take around 2s to start. Not sure about Ruby, since I don't have it enabled on boot. For comparison, Docker takes a little over 3s.

Check out the GitHub repo for the source code. Extra modules that are either really useful or really cool can be suggested for inclusion.

Also be sure to file any bugs there!