On my 2.9Ghz i7 with an EVO850 SSD running Ubuntu 12.04:
$ time python -c 'from pkg_resources import load_entry_point' python -c 'from pkg_resources import load_entry_point' 0.14s user 0.01s system 97% cpu 0.152 total
This means that using calls to the catkin script in tab-completion is a very laggy experience, and explains why there's a ubiquitous >200ms latency when running catkin commands. I think as it stands, catkin_tools is over-using the entry_points interface. For example it's not necessary for the main catkin command, nor is it really necessary for the built-in verbs.
I think the tool could be much more responsive if we used an alternative to entry_points for the verbs and build types. For example, mercurial uses a simple interface in .hgrc to specify plugins explicitly, and I think we would be better off using a system like that.
Currently catkin creates ~/.config/catkin and catkinrc could contain something like:
verbs: lint: catkin_lint.main build-types: catkin: catkin_tools.build_types.catkin cmake: catkin_tools.build_types.cmake ament: ament_pkg.catkin_plugin
Loading and reading a YAML file or INI is under 50ms:
$ time python -c 'import yaml; f = open(".config/catkin/verb_aliases/00-default-aliases.yaml","r"); print(yaml.load(f)); f.close();'
{'bt': 'b --this', 'p': 'create pkg', 'b': 'build', 'ls': 'list', 'install': 'config --install', 'test': 'build --verbose --make-args test --', 'run_tests': 'build --verbose --catkin-make-args run_tests --'}
python -c 0.04s user 0.02s system 94% cpu 0.064 total
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4