Closed mkropat closed 10 years ago
Unfortunately I think the bulk of the time is just spent loading the gem's dependencies. Startup time isn't ruby's strongest attribute, and rubygems has had various problems over the years which have contributed to slow loading of an app's environment (I believe some of these are fixed, but some remain).
I've done some tests locally and have similar numbers to what you report.
Sadly even doing something like this is fairly slow, and cuts timetrap's code entirely out of the equation:
$ time ruby -e 'require "sequel"'
real 0m0.380s
user 0m0.323s
sys 0m0.052s
In fact just loading the ruby 2.0 interpreter takes almost 100 ms on my laptop.
$ time ruby -e ''
real 0m0.086s
user 0m0.050s
sys 0m0.033s
I don't think there's any simple way to speed it up. One approach would be to preload the environment (either as a server that commands could be streamed to, or as a parent process that could be forked). Both these approaches seem like overkill for a tool like this.
Probably a better approach would be to just use the half second pause as an opportunity to reflect on the work you've just completed or are about to embark on.
I dig your philosophy. You're right, timetrap is still very usable. I will, however, think twice before ever creating a cli tool in Ruby.
My timetrap DB is getting quite large with many thousand entries and it has gotten much slower lately. Is there a way to move the archived entries in another DB or another way make it faster again?
Love the tool, but it is inexplicably slow for such a simple cli tool. Is this normal or is this something funky with my ruby? (I'm not a ruby guy.)
These are runtimes after everything is “warm” (delays are closer to 1s when cold):