Removing command line options from the config is a path towards cleaning up the
configuration file and not including options which don't really belong there.
The `ServeCommand` will let you serve your site locally for development. You
can specify `--port`, `--host` and `--baseurl` options if you wish to change the
defaults.
Additionally the `BuildCommand` will be called before the processing of the
serve command, this makes sure that the site is actually built. This means you
are able to pass the `--watch` option to auto-regenerate your site, even while
serving it locally.
The `BuildCommand` class is responsible for handling the building of the site.
It can also optionally watch for changes to files and regenerate the site if
needed.
The `Command` class holds any methods which are used by any command
implementation.
When a post has a title that contains a slash, such as 'This is my cool
blog post part 1/2', convert the slash to a dash so that the post
filename is created correctly.
Fixes issue #680
Currently, Classifier::LSI rebuilds the index every time an entry is
added. This runs into massive performance overheads on my website;
theoretically, disabling automatic index rebuilds, and explicitly
rebuilding the LSI index at the end of the LSI repopulation should
speed things up nicely.
As a side note, here, I use pandoc-ruby to provide a more featureful
Markdown transformer, so be mindful that the numbers I quote here have
artifically imposed I/O overheads.
With just the 76 posts I wrote this year (abysmal, I know), I come up
with the following figures:
Without faster_lsi:
jekyll --lsi 16.91s user 0.88s system 97% cpu 18.302 total
With faster_lsi:
jekyll --lsi 2.72s user 0.77s system 88% cpu 3.940 total
With 109 posts, we begin to see even better improvements:
Without faster_lsi:
jekyll --lsi 51.00s user 1.47s system 98% cpu 53.060 total
With faster_lsi:
jekyll --lsi 5.04s user 1.12s system 91% cpu 6.735 total
At this point, we begin to see I/O overheads being slower than LSI
when faster_lsi is active. I call that fairly conclusive. But wait,
there's more. I have 273 posts lying around... I wonder what happens
if I feed them all in. With faster_lsi, it was nice and clippy.
Without it, I simply gave up, and went and refilled my cup of tea.
And it was still going.
Without faster_lsi:
jekyll --lsi 1277.86s user 10.90s system 99% cpu 21:30.29 total
With faster_lsi:
jekyll --lsi 34.62s user 4.43s system 96% cpu 40.430 total
That is, in anyone's books, a major improvement. Note, however, that
I don't know just how well this will perform with `jekyll --auto`
because I don't know how it does the LSI rebuilds. I _think_ (but
please, don't commit me on this) that the LSI is rebuilt every time
Jekyll picks up a file change.
So, all up, the performance improvement is massive, and scales
depending on how many files you have. At the last point, the
improvement is just on 3200%.
A more optimal solution would be to cache the LSI index and/or content
data somehow. I'll leave that to when faster_lsi takes over ten
minutes to run.
Tom Preston-Werner
Tom Bell
Nat Welch
Tom Preston-Werner
edeustace
petedmarsh
Matt Rogers
Fabio Neves
Jashank Jeremy
Alagu
Will Brady
hokaccha
Neil-Smithline