I use Jekyll to build my site, and it is starting to take a rather long time (a few minutes) to compile the site (of a bit more than 600 posts). I suspect that some plugins might be responsible, but it seems there must be a better way to profile the performance of the build than to simply toggle on and off different plugins and parsers.
The minimal output during the build doesn't give any hints -- all the time is simply spent in the "building site" step. I thought I could run the jekyll script through ruby-prof to get some idea, so I made a quick local copy of the jekyll script as jekyll.rb in my site root directory and ran
ruby-prof jekyll.rb
The site looks like it builds fine, but the profiler just chokes with an ugly core dump.
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
Aborted (core dumped)
Is there a more intelligent way to profile the building process of my site and figure out why it's so slow?
Secondly, are there any tricks to speed up the compile time? (For instance, I see the existence of a _cache directory in _plugins, but don't know exactly what it does. I also see an --auto flag to Jekyll, but don't see how I could configure it such that it always recompiles certain pages wether or not they have changed (e.g. the twitter plugin needs to be re-run each time) while not recompiling the unchanged posts).
If anyone wants to poke around first-hand, the Jekyll source of the site is on Github, with some notes in the readme about additional gem dependencies.
Try Ruby GSL
gem install gsl
http://rb-gsl.rubyforge.org/
Should help speed up the build time.
Related
Very often we need to install software from its source code. Most of the time I just hit "make world" or "make all" then it will work like a charm. But some other time we see make errors, and we need to install other packages in order to let the make go through. This is particularly a problem for compiling low-level systems, such as a Linux kernel or Xen hypervisor.
I have one experience with Xen 3.4. Maybe it has been documented in some corner documents, but it depends on udev-125 to work properly. The weird thing is it functions well most of the time when udev version is 160+, it only breaks in certain cases! It took me a few MONTHS to find out it was because of the wrong udev version!
To make developers' life easier, when a source code is made successfully in one machine, is there some tools to record the list of packages and versions of that machine? Such a 'snapshot' should be shipped with the source code as well, so that when someone meets the make error they at least have a successful 'snapshot' for reference.
Is there such a tool already?
If your software depends on a specific version of a dependency, you should write a check for your configure script/cmakefile/etc. that tests the version of the dependency and bails out if the wrong version was found.
Comparing the output of config.log (a file created by a configure script) can also help diagnose problems like you encountered.
I'm just wondering if there is a way to integrate SASS into Jekyll. All that I need is an automatic .scss compilation into .css when I launch Jekyll.
I don't see anything wrong with compiling assets when you launch (which I take to mean run) jekyll. The whole point of running jekyll is to pre-compile your site, which is good for performance.
As for asset conversion-- there are many plugins available that focus on this. I like the Jekyll Asset Pipeline gem, which supports any language (e.g. Scss, Less, CoffeeScript, Erb, etc.) and has a bunch of features (e.g. asset tagging, compression, gzipping, etc.) that set it apart. It also seems to be the fastest growing Jekyll-related gem these days, which I take to mean that it is gaining traction in the community.
If you want to keep it as simple as compass watch you can use the Guard gem along with guard-jekyll and guard-compass (and if you like style injection, guard-livereload).
Guard bundles multiple 'watch' actions under a single terminal window, and is much easier to set up than a robust asset pipeline. Install the gems, configure the .guardfile according to the guard-compass and guard-jekyll instructions, cd to your directory and type guard. Any time a relevant file changes your sass files and/or jekyll site will be recompiled.
Native Sass, and CoffeeScript, processing debuted in Jekyll v2.0:
http://jekyllrb.com/docs/assets/#sassscss
Full disclosure: I am the lead dev behind this project.
The easiest way I've seen to setup Sass with Jekyll is with jekyll-compass. This gem will do exactly as you describe: Any time jekyll builds your website (jekyll build, jekyll serve, etc) your Sass will be compiled into the output folder along with the rest of your website. Check out the readme linked above for full usage details.
There's also some work under way currently by the Jekyll guys to get Sass support into the core of Jekyll so that everyone will have at least basic access to Sass and the wonderful feature-set it provides.
I'm using Octopress as my blog engine. It's perfect. But if there are many posts, for example 400+ posts, the speed of generation is soooo slow.
So, is there any way to speed up Jekyll/Octopress generation?
Thanks.
Obviously if you are just working on one post, there is no need to wait for the entire site to generate. What you are looking for is the rake isolate[partial_post_name] task.
Using rake isolate, you can “isolate” only that post you are working on and move all the others to the source/_stash folder. The partial_post_name parameter is just some words in the file name for the post. For example, if I want to isolate the post from the earlier example, I would use
rake isolate[plain-english]
This will move all the other posts to source/_stash and only keep the 2011-09-29-just-type-the-title-of-the-post-here-in-plain-english.markdown post in source/_posts. You can also do this while you are running rake preview. It will just detect a massive change and only regenerate that one post from then on.
by #Pavan Podila
More Info: Tips for Speeding Up Octopress Site Generation
2013.01.08 update:
Hexo--A fast, simple & powerful blog framework, powered by Node.js.
Features:Incredibly fast - generate static files in a glance
2013.6.20 update:
gor -- A static websites and blog generator engine written in Go
gor has following awesome benefits: 1. Speed -- Less than 1 second when compiling all my near 200 blogs on wendal.net 2. Simple -- Only one single executable file generated after compiling, no other dependence
Install Ruby GSL
gem install gsl
You should notice a speed increase.
hexo powered by Node.js. I am using it, much faster than Octopress. And it provides a simple way to migrate your articles to hexo very easily.
You can generate only one post while you are writing it using
rake isolate[your-post]
and then
rake integrate
to go back to normal.
To fully answer your question, you can't generate only one post. You can see Octopress' Issue #395 on that subject, which explains that this is due to a limitation on Jekyll's side.
Reached this post with the same problem, but then did not quite like the idea of rake isolate. Also the inbuilt task does not integrate with the _drafts workflow.
So what I ended up using is to create a custom config.yml with the _posts folder excluded (using exclude) and have only the drafts folder built. You can pass in a different config file as command line parameter to jekyll. I just used this when actively writing new posts and while publish use the same old approach (which still does take some time). This approach builds only the draft post and I am good with that.
jekyll build --watch --drafts --config _previewconfig.yml
For those interested in the complete worklow take a look here
If your blog has a lot of images (and other static assets that do not change between builds), it is worthwhile to exclude them from Jekyll's build process, and instead manually update them as needed.
For whatever reason, Jekyll build is not intelligent when it comes to handling such assets. It will delete everything in the public folder, and re-copy the contents in source every time you build. This is wasteful if the assets haven't changed. This can be avoided by using a tool such as Robocopy (Windows) or Rsync (Linux) that is able to update only what has changed.
To tell Jekyll to ignore a folder, add the following to _config.yml:
exclude: # exclude from build
- folderPath
keep-files: # do not delete/empty copy in `public`
- folderPath
Then elsewhere, use whatever tool you want to update the folder.
For more things you can try, see this post.
After years of being away from Ruby, I'm back full-force and have just cut my first gem, which includes an executable. Everything works like a charm.
The problem I am facing, however, is that I ALSO have a startup script (not part of the gem istelf) that daemonizes the executable. Additionally, I'd also like for the startup script to point the executable at configuration in a place like /var/
To the best of my knowledge, there's no way with rubygems, gemspec, etc., to specify files getting blown out to other parts of your system during install (e.g. startup script to /etc/init.d, and config to /var/). It certainly wouldn't make sense if you COULD do that.
So... my question is... what IS the proper procedure for automating the installation of something like this. I'm using RHEL, and am wondering if it's, perhaps, time for me to get my feet wet with making my first RPM.
Any thoughts?
You can do it. However it is probably not quite the recommended approach. But yes it is possible to run arbitary code during gem installation using the extensions option.
From the RubyGems Manual:
Usage
spec.extensions << 'ext/rmagic/extconf.rb'
Notes
These files will be run when the gem is installed, causing the
C (or whatever) code to be compiled on the user’s machine.
Just place whatever ruby code you need into the extconf.rb (or equivalent) file.
Examples for building C-extensions from the RubyGems Guides:
http://guides.rubygems.org/c-extensions/
I've got a ruby web app that uses lilypond to generate sheet music based on user input. I'd like to move the hosting to heroku (I've recently used heroku on a few projects and really liked it, plus my traffic is low enough that it'd be free host it on heroku, for a while at least). However, heroku's dyno architecture doesn't allow you to ssh in and install whatever packages you want...instead, you give it a gems manifest, and it will install the gems for you.
So, if I'm going to deploy to heroku, I'm going to need to package lilypond as a gem. I've released a few pure-ruby gems, but haven't dealt with native extensions or precompiled binaries, or anything like that.
Is it possible to take some precompiled binaries and package it inside a gem? Ideally, this would include binaries for OS X (which I develop on) and debian linux (which is what's running on heroku), and would install the proper binary when the gem was installed.
it is possible, since precompiled binary gems for windows are the norm. Take a look at rake compiler, perhaps.
also https://github.com/rdp/ruby_tutorials_core/wiki/gem (https://en.wikibooks.org/wiki/Ruby_Programming/RubyGems) might help
-r
I think you've got a few options here:
You could get the Lilypond source and package it into a gem with a native C extension. There are some useful guides on how to do that at http://guides.rubygems.org/c-extensions/ and http://patshaughnessy.net/2011/10/31/dont-be-terrified-of-building-native-extensions
There's also a gem called gitara but I haven't been able to find any information about using it on Heroku. It might be worth emailing the author and asking if he knows anything about that.
You could create a Heroku buildpack that installs Lilypond as part of your deployment. I wasn't able to find any for Lilypond, but there are plenty of examples that do similar things - for example, this one installs Imagemagick (which is included by default on Heroku, so probably not necessary anymore - but hopefully the code is helpful). More documentation at https://devcenter.heroku.com/articles/buildpack-api and https://devcenter.heroku.com/articles/buildpack-binaries
Based on my reading, I think the buildpack option is the best way to go.
Hopefully this helps!
Instead of precompiling, you should be able to just list the gem in your .gems file, see the Heroku documentation. Of course, this requires your gem builds the native code correctly - this is still a task, but hopefully an easier one.