I can't solve the time it takes for a full site build, but I've come up with a way to dramatically speed up drafting documents and making layout changes. All of this assumes you work on a local machine for editing and then deploy to a production server. Your mileage may vary if you have a different process.
The core idea is to use multiple jekyll source directories that each point to the same output location. In my case, I use three. One for drafting and editing posts (called '_drafts'), one for layout, design and functionality changes (called '_dev') and the final one that contains the contents of the full site (called '_main').
The top level directory structure looks like this:
./_drafts
./_dev
./_main
./html
The _config.yml file for each jekyll source is setup with the follow to point the jekyll generated output to the 'html' directory:
destination: ../html
The '_drafts' and '_dev' directories contain the minimum number of files necessary to make them mimic the design and functionality of the '_main' site. I do all my work in those two directories with jekyll running in whichever is being worked on. My local web server is setup to point a local domain (e.g. http://jekyll-test/) to the 'html' directory so I can see what's going on while I'm making changes.
When I'm finished editing, I copy the newly updated files from '_dev' or '_drafts' to their corresponding location in '_main'. Once the files are in place, I do one final jekyll run in '_main'. With this approach, you only have to wait through the long site generation time once before deploying the site to production. I've been using this approach for some time and find it makes a huge difference.
There are some other ways to optimize the workflow:
Use symbolic links to help keep the design and functionality of '_drafts' and '_main' in sync.
If you are on a Mac or linux machine, setup symbolic links to point ./_drafts/_config.yml to ./main/_config.yml and ./_drafts/_layouts to ./main/_layouts (Similar functionality probably exist on Windows, but I can't speak to it). For some reason, jekyll won't work well with some directories symbolically linked. For example, on my install, I have a root level 'css' directory that doesn't work as a sym link. I have to have an actual copy of it in all locations.
Create a deployment script.
When I'm ready to deploy, I don't run jekyll directly. I've written a little script the calls jekyll in the '_main' directory, rsyncs the output to my production server and then notifies me when it's complete. Not only does this save having to wait on jekyll, it reduces the number of steps required to deploy the site.
Build additional scripts and tools.
Copying the files from the '_dev' and '_drafts' directory isn't a big deal, but it's a prime place to add some automation. For example, I have a command line script that copies the '_config.yml' file and the '_layouts' and 'css' directories from '_dev' to both '_drafts' and '_main' (as necessary).
Another tool on the docket is a local web app that will move posts from '_drafts' into '_main'. Anything that makes the movement of files easier and reduces the friction of creating and publishing is good.
Use LiveReload
Running locally, jekyll --auto is great for automatically generating your changes while working on files. The natural companion to this is an app called LiveReload. It watches your local 'html' directory and triggers an automatic reload of your browser when the contents change. The net of this is that you can keep your browser window beside your text editor and see changes happen automatically when you save a file. It's a little flaky from time to time, but after using it, you won't know how you lived without it.
--autoflag works only when jekyll--serveris already running during the changes. i.e. if you have your webserver runningjekyll --server --autoall the time, and you push your changes to it. Jekyll isn't tracking which pages have changed in between subsequent calls tojekyll --server. – Extortionate