Jenv: export plugin extremely slows down shell response

Created on 29 Oct 2017  ·  4Comments  ·  Source: jenv/jenv

After jenv enable-plugin export, shell response is extremely slow.

$ # <= type enter here
$ # shell is active after about 0.3 seconds (slow!)
  • bash version: 4.4.12(1)-release (x86_64-apple-darwin16.3.0)
  • jenv 0.4.4

( time command doesn't reflect the slowness)

Most helpful comment

I'm also on jenv 0.4.4 (but installed by homebrew via brew install jenv).

This happens because the _jenv_export_hook function in $HOME/.jenv/plugins/export/etc/jenv.d/init/export_jenv_hook.bash is called by bash on every prompt display when evaluating $PROMPT_COMMAND

Ordinarily this is ok, but _jenv_export_hook calls jenv javahome to set the JAVA_HOME value. I think jenv javahome is the culprit here, and it might only be a problem on newer Mac OS X versions.

I'm currently running bash 4.4.19(1)-release (x86_64-apple-darwin15.6.0), and that darwin version implies Mac OS X El Capitan (10.11.6).

Here is my runtime of jenv javahome:

[me:~] $ time jenv javahome
/Users/me/.jenv/versions/1.8

real    0m0.089s
user    0m0.035s
sys 0m0.043s

A co-worker has a newer laptop and he's running bash version 4.4.19(1)-release (x86_64-apple-darwin17.3.0 (same exact bash version as me, just on Mac OS X High Sierra 10.13.4). Here's his jenv javahome time:

[him:~] $ time jenv javahome
/Users/him/.jenv/versions/1.8

real    0m1.029s
user    0m0.041s
sys    0m0.077s

That's 1.029 seconds of delay every time a bash prompt is displayed, even within the same terminal window (in other words, the delay isn't just experienced when opening a new terminal window - it's experienced every time the prompt is redisplayed).

Based on this, is there a workaround that can be implemented?

For example - is the export plugin even necessary? (I'm just thinking out loud - I don't know for sure)

An alternative that I've always used in my self-managed installations (before finding jenv) was to have a 'current' symlink that pointed to the desired JDK. Or in jenv's case, maybe call it global to retain current nomenclature.

Based on this, I think we can do away with the export plugin based on the following:

  • running jenv global {version} would ensure that a symlink ~/.jenv/versions/global existed and pointed to one of the existing symlinks in ~/.jenv/versions and and export JAVA_HOME="$HOME/.jenv/versions/global" line would be in the output of jenv init -.

  • running jenv shell {version} has the same effect of running export JAVA_HOME="$HOME/.jenv/versions/{version}" for the current shell only and doesn't modify the global symlink.

  • not sure what else is required for jenv local {version}.

Maybe this could greatly speed up things if not solve them entirely. Thoughts?

All 4 comments

I'm also on jenv 0.4.4 (but installed by homebrew via brew install jenv).

This happens because the _jenv_export_hook function in $HOME/.jenv/plugins/export/etc/jenv.d/init/export_jenv_hook.bash is called by bash on every prompt display when evaluating $PROMPT_COMMAND

Ordinarily this is ok, but _jenv_export_hook calls jenv javahome to set the JAVA_HOME value. I think jenv javahome is the culprit here, and it might only be a problem on newer Mac OS X versions.

I'm currently running bash 4.4.19(1)-release (x86_64-apple-darwin15.6.0), and that darwin version implies Mac OS X El Capitan (10.11.6).

Here is my runtime of jenv javahome:

[me:~] $ time jenv javahome
/Users/me/.jenv/versions/1.8

real    0m0.089s
user    0m0.035s
sys 0m0.043s

A co-worker has a newer laptop and he's running bash version 4.4.19(1)-release (x86_64-apple-darwin17.3.0 (same exact bash version as me, just on Mac OS X High Sierra 10.13.4). Here's his jenv javahome time:

[him:~] $ time jenv javahome
/Users/him/.jenv/versions/1.8

real    0m1.029s
user    0m0.041s
sys    0m0.077s

That's 1.029 seconds of delay every time a bash prompt is displayed, even within the same terminal window (in other words, the delay isn't just experienced when opening a new terminal window - it's experienced every time the prompt is redisplayed).

Based on this, is there a workaround that can be implemented?

For example - is the export plugin even necessary? (I'm just thinking out loud - I don't know for sure)

An alternative that I've always used in my self-managed installations (before finding jenv) was to have a 'current' symlink that pointed to the desired JDK. Or in jenv's case, maybe call it global to retain current nomenclature.

Based on this, I think we can do away with the export plugin based on the following:

  • running jenv global {version} would ensure that a symlink ~/.jenv/versions/global existed and pointed to one of the existing symlinks in ~/.jenv/versions and and export JAVA_HOME="$HOME/.jenv/versions/global" line would be in the output of jenv init -.

  • running jenv shell {version} has the same effect of running export JAVA_HOME="$HOME/.jenv/versions/{version}" for the current shell only and doesn't modify the global symlink.

  • not sure what else is required for jenv local {version}.

Maybe this could greatly speed up things if not solve them entirely. Thoughts?

I am finding the same issue of slowness on jenv 0.5.3 with the export plugin enable in zsh. Using the zsh/zprof i am getting that this is the main slow factor on the shell startup time

$ zsh -i -c exit | head -5
num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    1         133,57   133,57   81,40%    133,57   133,57   81,40%  _jenv_export_hook
 2)    1          12,78    12,78    7,79%     12,78    12,78    7,79%  compinit
 3)    7           8,10     1,16    4,94%      5,92     0,85    3,61%  (anon)

Thank you.

I will check if we can improve things.

@gcuisinier Do you have any updates on this issue? I can definetely feel the difference if I disable jenv plugin in zsh. jenv version 0.5.4

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hanxue picture hanxue  ·  3Comments

rexgreen picture rexgreen  ·  8Comments

HeIsIdeus picture HeIsIdeus  ·  9Comments

c0nscience picture c0nscience  ·  3Comments

doctorpangloss picture doctorpangloss  ·  5Comments