New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jekyll needs too much time to compile #1855

Closed
MartinThoma opened this Issue Dec 19, 2013 · 24 comments

Comments

Projects
None yet
@MartinThoma

MartinThoma commented Dec 19, 2013

When I compile my blog (source, rendered) it takes about 6 minutes. This is much too long. I think it should only take about 5 seconds.
(Compared to WordPress, I can "preview" a post and it only needs less than a second for the same blog)

I know that there are blogs that compile much faster (see #1806), but it seems to me that you have to invest more time in fast blog generation than necessary. At least, it would be good to publish some guidelines how to improve website generation time.

@doktorbro

This comment has been minimized.

Show comment
Hide comment
@doktorbro

doktorbro Dec 20, 2013

Member

I think it should only take about 5 seconds.

Why not 4 seconds? Or 3? Your homepage needs 6.6 seconds to fully load at the DSL speed. I think it should only take under 2 seconds. It seems to me that you have to invest:

  • more time in frontend development — remove the sidebar and custom fonts
  • more money in fast hardware — generate your blog on your own super fast computer

And use markdown. With markdown you can see how the post will look while you writing it. So you don’t need to extra preview all the time.

Member

doktorbro commented Dec 20, 2013

I think it should only take about 5 seconds.

Why not 4 seconds? Or 3? Your homepage needs 6.6 seconds to fully load at the DSL speed. I think it should only take under 2 seconds. It seems to me that you have to invest:

  • more time in frontend development — remove the sidebar and custom fonts
  • more money in fast hardware — generate your blog on your own super fast computer

And use markdown. With markdown you can see how the post will look while you writing it. So you don’t need to extra preview all the time.

@MartinThoma

This comment has been minimized.

Show comment
Hide comment
@MartinThoma

MartinThoma Dec 20, 2013

Why not 4 seconds? Or 3?

Would be fine, too. I just wanted to show expectations from a users perspective.

Yes, I know that my site should load faster. But I don't want to remove the sidebar, because I think it looks nice.

It seems to me that you have to invest more money in fast hardware

So you suggest buying a computer that is roughly 100 times as fast. Seriously?

With markdown you can see how the post will look while you writing it. So you don’t need to extra preview all the time.

No, that's not correct. Markdown does not display images; Markdown does not show the inserted TOC; Markdown does not render LaTeX, ...

MartinThoma commented Dec 20, 2013

Why not 4 seconds? Or 3?

Would be fine, too. I just wanted to show expectations from a users perspective.

Yes, I know that my site should load faster. But I don't want to remove the sidebar, because I think it looks nice.

It seems to me that you have to invest more money in fast hardware

So you suggest buying a computer that is roughly 100 times as fast. Seriously?

With markdown you can see how the post will look while you writing it. So you don’t need to extra preview all the time.

No, that's not correct. Markdown does not display images; Markdown does not show the inserted TOC; Markdown does not render LaTeX, ...

@doktorbro

This comment has been minimized.

Show comment
Hide comment
@doktorbro

doktorbro Dec 20, 2013

Member

I’ve downloaded your source (140 MB). The plugin directory contains 12 (!) rb-files. I execute:

time jekyll build

# later

done.

real  9m1.806s
user  8m8.911s
sys   0m6.332s

My setup:

  • 2,0 GB memory
  • Intel® Core™2 Duo CPU T5750 @ 2.00GHz × 2
  • old slow laptop harddrive
  • ruby 1.9.3

I would say, my performance is in the same class as yours. Remove all plugins, remove the useless sidebar and try it again.

Member

doktorbro commented Dec 20, 2013

I’ve downloaded your source (140 MB). The plugin directory contains 12 (!) rb-files. I execute:

time jekyll build

# later

done.

real  9m1.806s
user  8m8.911s
sys   0m6.332s

My setup:

  • 2,0 GB memory
  • Intel® Core™2 Duo CPU T5750 @ 2.00GHz × 2
  • old slow laptop harddrive
  • ruby 1.9.3

I would say, my performance is in the same class as yours. Remove all plugins, remove the useless sidebar and try it again.

@troyswanson

This comment has been minimized.

Show comment
Hide comment
@troyswanson

troyswanson Dec 20, 2013

Member

Throwing more hardware at the problem isn't a viable solution. Performance gains can only be realized by optimizing for the system that you're working with.

I didn't go deep into your source, but I found this:

<span>{% assign d = page.date | date: "%d" | plus:'0' %}
    {{ page.date | date: "%B" }} 
    {% case d %}
        {% when 1 or 21 or 31 %}{{ d }}st
        {% when 2 or 22 %}{{ d }}nd
        {% when 3 or 23 %}{{ d }}rd
        {% else %}{{ d }}th
    {% endcase %}, 
    {{ page.date | date: "%Y" }}
</span>

Stuff like this, you need to throw into a decision tree. Is the benefit of this string greater than the cost of you waiting for your site to generate? It's a decision only you can make. I'm sure there are several of these instances that you can identify and determine for yourself whether or not they're worth it.

At the end of the day, you can have complex templates, but you'll be trading render performance for it. Or you can have simple templates that render really quickly. Everyone's audience is different, so it's up to you!

Markdown does not display images

The image syntax for Markdown is: ![Alt text](http://path/to/img.jpg)

Markdown does not show the inserted TOC

Check out #1774 for a discussion about using vmg/redcarpet for table of contents

Compared to WordPress, I can "preview" a post and it only needs less than a second for the same blog

Comparing Jekyll to WordPress is like comparing a baseball to football. Sure, they are both sports, but that's about as far as the similarities go. Same for Jekyll and WordPress. They both can generate websites, but that's about it when it comes to similarities.

Hope this helped! 😄

Member

troyswanson commented Dec 20, 2013

Throwing more hardware at the problem isn't a viable solution. Performance gains can only be realized by optimizing for the system that you're working with.

I didn't go deep into your source, but I found this:

<span>{% assign d = page.date | date: "%d" | plus:'0' %}
    {{ page.date | date: "%B" }} 
    {% case d %}
        {% when 1 or 21 or 31 %}{{ d }}st
        {% when 2 or 22 %}{{ d }}nd
        {% when 3 or 23 %}{{ d }}rd
        {% else %}{{ d }}th
    {% endcase %}, 
    {{ page.date | date: "%Y" }}
</span>

Stuff like this, you need to throw into a decision tree. Is the benefit of this string greater than the cost of you waiting for your site to generate? It's a decision only you can make. I'm sure there are several of these instances that you can identify and determine for yourself whether or not they're worth it.

At the end of the day, you can have complex templates, but you'll be trading render performance for it. Or you can have simple templates that render really quickly. Everyone's audience is different, so it's up to you!

Markdown does not display images

The image syntax for Markdown is: ![Alt text](http://path/to/img.jpg)

Markdown does not show the inserted TOC

Check out #1774 for a discussion about using vmg/redcarpet for table of contents

Compared to WordPress, I can "preview" a post and it only needs less than a second for the same blog

Comparing Jekyll to WordPress is like comparing a baseball to football. Sure, they are both sports, but that's about as far as the similarities go. Same for Jekyll and WordPress. They both can generate websites, but that's about it when it comes to similarities.

Hope this helped! 😄

@jashank

This comment has been minimized.

Show comment
Hide comment
@jashank

jashank Dec 31, 2013

Contributor

The best guideline I can think of for Jekyll (and it's not even anything to do with Jekyll) is: Liquid is slow.

Jekyll will happily spit out thousands of pages in seconds, but any time you make a call into Liquid, you get a performance hit. When you have something akin to the chunk @troyswanson singled out, you almost certainly have just found your bottleneck.

Another great hint: Jekyll's layouts can nest, and experimentation has found this is ~1.5x faster than Liquid includes for huge numbers of pages.

Running the build for your site OOTB took ~3m30s. I did some fiddling (I blanked everything in _layouts and replaced them all with a single call to {{ content }}), which reduced it to ~3m10s. More fiddling (of the "remove everything in _plugins and put stuff back if it's not a trivial fix" variety) got the build down to 13 seconds.

I'm deeply suspicious of database_generator, rss_generator and sitemap_generator. The latter two can be replaced by a simple template (see the way mojombo did RSS/Atom and the way I do sitemap.xml).The former would require some thought, but I'd suspect if it's being used as a search database that generating a JSON blob would be faster and cheaper than a whole SQLite DB (and yes, I know how lightweight SQLite is).

Move minifying CSS into the Makefile, which pulls it's build time out of Jekyll (and doesn't really need to be rebuilt each time anyway). Otherwise, you've done some good work already in getting the build time down from ~6m. HTH!

Contributor

jashank commented Dec 31, 2013

The best guideline I can think of for Jekyll (and it's not even anything to do with Jekyll) is: Liquid is slow.

Jekyll will happily spit out thousands of pages in seconds, but any time you make a call into Liquid, you get a performance hit. When you have something akin to the chunk @troyswanson singled out, you almost certainly have just found your bottleneck.

Another great hint: Jekyll's layouts can nest, and experimentation has found this is ~1.5x faster than Liquid includes for huge numbers of pages.

Running the build for your site OOTB took ~3m30s. I did some fiddling (I blanked everything in _layouts and replaced them all with a single call to {{ content }}), which reduced it to ~3m10s. More fiddling (of the "remove everything in _plugins and put stuff back if it's not a trivial fix" variety) got the build down to 13 seconds.

I'm deeply suspicious of database_generator, rss_generator and sitemap_generator. The latter two can be replaced by a simple template (see the way mojombo did RSS/Atom and the way I do sitemap.xml).The former would require some thought, but I'd suspect if it's being used as a search database that generating a JSON blob would be faster and cheaper than a whole SQLite DB (and yes, I know how lightweight SQLite is).

Move minifying CSS into the Makefile, which pulls it's build time out of Jekyll (and doesn't really need to be rebuilt each time anyway). Otherwise, you've done some good work already in getting the build time down from ~6m. HTH!

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Dec 31, 2013

Member

We can't be responsible for the extra compile time added by any custom plugins you've added to your site. As @jashank pointed out, the extra plugins and other things in your site are what's causing your long compile times. Since there's other ways to do what you want and we're already working on the long compile time problem from the Jekyll core point of view (#380), I'll close this issue.

Member

mattr- commented Dec 31, 2013

We can't be responsible for the extra compile time added by any custom plugins you've added to your site. As @jashank pointed out, the extra plugins and other things in your site are what's causing your long compile times. Since there's other ways to do what you want and we're already working on the long compile time problem from the Jekyll core point of view (#380), I'll close this issue.

@mattr- mattr- closed this Dec 31, 2013

@MartinThoma

This comment has been minimized.

Show comment
Hide comment
@MartinThoma

MartinThoma Jan 1, 2014

@mattr- Even without any plugins (well, except for caption_tag.rb, tag-cloud.rb and CssMinify.rb) jekyll needs about 30 seconds. Yes, that's much less than with plugins and I should try to improve my plugins first. But many years ago, I've written a static site generator with PHP that needed only a fraction of a second to run (with my own templating language which was by far not as powerful as Liquid and without markdown support). So I think it should be possible to improve this. Also, it is not only my impression that this should be faster:

I think the idea of building a performance page (#1806 (comment)) could help a lot. Do you think it is possible that Jekyll gives information about the execution time of plugins? Or maybe a switch could be added so that jekyll logs something like [Info][0m12s] Started plugin 'database_generator.rb'. This would make it easier to see at a glance when one plugin causes most of the execution time.

For my plugins, I've just tested the plugins this way:

  1. Remove all plugins (except for caption_tag.rb, tag-cloud.rb and CssMinify.rb, because without them the site does not compile)
  2. t1 = time make test to build the site and get time
  3. Add plugin I want to test
  4. t2= time make test again
  5. => Plugin needs roughly t2 - t1 time

With this, I got:

  • database_generator.rb: ~16minutes 36seconds
  • author_generator.rb: ~3minutes 20 seconds
  • _tag_gen.rb: ~1minut 56seconds
  • _cat_gen.rb: ~ 5 seconds
  • rssgenerator.rb: ~4 seconds
  • tocGenerator.rb: ~2 seconds
  • category_slug_tag.rb: < 1 second
  • sitemap_generator.rb: < 1 second
  • slugify.rb: <1 second

So, obviously I take database_generator.rb out if I don't need it. (I want to use a dynamic search as I didn't find any good static search alternatives. For this dynamic, PHP+SQLite based search I need a SQLite database).

But why does author_generator.rb take so long?

@jashank: Thank you for giving me hints how to speed up Jekyll! I was looking for something like this. Maybe some "speed hints" could be added to http://jekyllrb.com/docs/troubleshooting/?

MartinThoma commented Jan 1, 2014

@mattr- Even without any plugins (well, except for caption_tag.rb, tag-cloud.rb and CssMinify.rb) jekyll needs about 30 seconds. Yes, that's much less than with plugins and I should try to improve my plugins first. But many years ago, I've written a static site generator with PHP that needed only a fraction of a second to run (with my own templating language which was by far not as powerful as Liquid and without markdown support). So I think it should be possible to improve this. Also, it is not only my impression that this should be faster:

I think the idea of building a performance page (#1806 (comment)) could help a lot. Do you think it is possible that Jekyll gives information about the execution time of plugins? Or maybe a switch could be added so that jekyll logs something like [Info][0m12s] Started plugin 'database_generator.rb'. This would make it easier to see at a glance when one plugin causes most of the execution time.

For my plugins, I've just tested the plugins this way:

  1. Remove all plugins (except for caption_tag.rb, tag-cloud.rb and CssMinify.rb, because without them the site does not compile)
  2. t1 = time make test to build the site and get time
  3. Add plugin I want to test
  4. t2= time make test again
  5. => Plugin needs roughly t2 - t1 time

With this, I got:

  • database_generator.rb: ~16minutes 36seconds
  • author_generator.rb: ~3minutes 20 seconds
  • _tag_gen.rb: ~1minut 56seconds
  • _cat_gen.rb: ~ 5 seconds
  • rssgenerator.rb: ~4 seconds
  • tocGenerator.rb: ~2 seconds
  • category_slug_tag.rb: < 1 second
  • sitemap_generator.rb: < 1 second
  • slugify.rb: <1 second

So, obviously I take database_generator.rb out if I don't need it. (I want to use a dynamic search as I didn't find any good static search alternatives. For this dynamic, PHP+SQLite based search I need a SQLite database).

But why does author_generator.rb take so long?

@jashank: Thank you for giving me hints how to speed up Jekyll! I was looking for something like this. Maybe some "speed hints" could be added to http://jekyllrb.com/docs/troubleshooting/?

@MartinThoma

This comment has been minimized.

Show comment
Hide comment
@MartinThoma

MartinThoma Jan 7, 2014

I'm not sure if anybody is interested in my tries to speed up my build process. But as this is closed, I guess it doesn't harm to document it.

I've just deactivated a couple of plugins:

  • database_generator.rb: Now I use "Google Custom Search Engine" for search. So I don't need to generate the search index.
  • author_generator.rb: Is now a single post for each author. (So Liquid replaces this plugin)
  • rssgenerator.rb: Is now a post. (So Liquid replaces this plugin)
  • sitemap_generator.rb: Is now a post. (So Liquid replaces this plugin)

Now the whole process (preprocess.py + jekyll with plugins + postprocess.py + commit&push) needs about 180 seconds.

MartinThoma commented Jan 7, 2014

I'm not sure if anybody is interested in my tries to speed up my build process. But as this is closed, I guess it doesn't harm to document it.

I've just deactivated a couple of plugins:

  • database_generator.rb: Now I use "Google Custom Search Engine" for search. So I don't need to generate the search index.
  • author_generator.rb: Is now a single post for each author. (So Liquid replaces this plugin)
  • rssgenerator.rb: Is now a post. (So Liquid replaces this plugin)
  • sitemap_generator.rb: Is now a post. (So Liquid replaces this plugin)

Now the whole process (preprocess.py + jekyll with plugins + postprocess.py + commit&push) needs about 180 seconds.

@mhulse

This comment has been minimized.

Show comment
Hide comment
@mhulse

mhulse Jan 7, 2014

Thanks for the update. I find this info helpful.

180 seconds.

That seems long, still. Maybe you mean milliseconds? How many pages?

mhulse commented Jan 7, 2014

Thanks for the update. I find this info helpful.

180 seconds.

That seems long, still. Maybe you mean milliseconds? How many pages?

@pathawks

This comment has been minimized.

Show comment
Hide comment
@pathawks

pathawks Jan 8, 2014

Member

Those three plugins that you cannot deactivate must be just beastly.

Member

pathawks commented Jan 8, 2014

Those three plugins that you cannot deactivate must be just beastly.

@MartinThoma

This comment has been minimized.

Show comment
Hide comment
@MartinThoma

MartinThoma Jan 8, 2014

@mhulse No, I mean seconds. I currently have 365 posts and 95 drafts.

$ time make test
...
... many messages ...
...
real    224.91s
user    152.12s
sys 3.26s

@pathawks I don't know what you want to say. If I remove these plugins (caption_tag.rb, tag-cloud.rb, CssMinify.rb and meanwhile gallery_tag.rb) I would have to remove the Liquid tags in all posts. I've used caption 521 times and I don't want to modify that many posts.

MartinThoma commented Jan 8, 2014

@mhulse No, I mean seconds. I currently have 365 posts and 95 drafts.

$ time make test
...
... many messages ...
...
real    224.91s
user    152.12s
sys 3.26s

@pathawks I don't know what you want to say. If I remove these plugins (caption_tag.rb, tag-cloud.rb, CssMinify.rb and meanwhile gallery_tag.rb) I would have to remove the Liquid tags in all posts. I've used caption 521 times and I don't want to modify that many posts.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jan 8, 2014

Member

@MartinThoma As has been said before, Liquid is a bit of a performance bottleneck right now. They're working on speeding it up for 3.0, but 2.5.x is still a bit laggy. Every call to Liquid slows down the build just a bit. Maybe @fw42 has some thoughts on this?

Member

parkr commented Jan 8, 2014

@MartinThoma As has been said before, Liquid is a bit of a performance bottleneck right now. They're working on speeding it up for 3.0, but 2.5.x is still a bit laggy. Every call to Liquid slows down the build just a bit. Maybe @fw42 has some thoughts on this?

@fw42

This comment has been minimized.

Show comment
Hide comment
@fw42

fw42 Jan 8, 2014

Contributor

I'm missing some context and I'm not familiar with Jekyll at all. Why and where exactly is Liquid a bottleneck?

Contributor

fw42 commented Jan 8, 2014

I'm missing some context and I'm not familiar with Jekyll at all. Why and where exactly is Liquid a bottleneck?

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jan 8, 2014

Member

@fw42 In convertible.rb, we create a new Liquid context for each page (as variables assigned in each page should not be accessible in other pages) and so we can set the page variable. For some reason currently unknown to me, every time we run a post through our converter's Liquid parser/renderer, it slows the build down significantly. One great example is a Liquid for loop. We added a news section to jekyllrb.com a few months ago and introduced two or three for loops. Even with 0 posts, it added an extra 3 seconds to the build time. I don't mind that much when we push out to production because GitHub Pages has to deal with that and not me, but it's difficult to develop with to have such a significant delay by just adding a few items to the array we're looping over.

Member

parkr commented Jan 8, 2014

@fw42 In convertible.rb, we create a new Liquid context for each page (as variables assigned in each page should not be accessible in other pages) and so we can set the page variable. For some reason currently unknown to me, every time we run a post through our converter's Liquid parser/renderer, it slows the build down significantly. One great example is a Liquid for loop. We added a news section to jekyllrb.com a few months ago and introduced two or three for loops. Even with 0 posts, it added an extra 3 seconds to the build time. I don't mind that much when we push out to production because GitHub Pages has to deal with that and not me, but it's difficult to develop with to have such a significant delay by just adding a few items to the array we're looping over.

@fw42

This comment has been minimized.

Show comment
Hide comment
@fw42

fw42 Jan 8, 2014

Contributor

Hm, that's really strange, because Liquid is usually pretty fast in our experience.

Contributor

fw42 commented Jan 8, 2014

Hm, that's really strange, because Liquid is usually pretty fast in our experience.

@fw42

This comment has been minimized.

Show comment
Hide comment
@fw42

fw42 Jan 8, 2014

Contributor

I think @csaunders looked into Jekyll+Liquid performance a few weeks ago. Maybe he has something to add.

Contributor

fw42 commented Jan 8, 2014

I think @csaunders looked into Jekyll+Liquid performance a few weeks ago. Maybe he has something to add.

@jashank

This comment has been minimized.

Show comment
Hide comment
@jashank

jashank Feb 4, 2014

Contributor

Following up on my comments about how to do search, try slashdotdash/jekyll-lunr-js-search, which does exactly what I suggested (and I had no idea of it's existence at the time): it generates a JSON blob of search data, which is then handled in the browser by lunr.js.

Contributor

jashank commented Feb 4, 2014

Following up on my comments about how to do search, try slashdotdash/jekyll-lunr-js-search, which does exactly what I suggested (and I had no idea of it's existence at the time): it generates a JSON blob of search data, which is then handled in the browser by lunr.js.

@chrishough

This comment has been minimized.

Show comment
Hide comment
@chrishough

chrishough Apr 16, 2014

Has there been any progress on this slowness issue?

chrishough commented Apr 16, 2014

Has there been any progress on this slowness issue?

@chrishough

This comment has been minimized.

Show comment
Hide comment
@chrishough

chrishough Apr 16, 2014

can I ask a dumb ? as I am running into build issues. what is the time command you are using? where can i get that?

chrishough commented Apr 16, 2014

can I ask a dumb ? as I am running into build issues. what is the time command you are using? where can i get that?

@csaunders

This comment has been minimized.

Show comment
Hide comment
@csaunders

csaunders Apr 16, 2014

If you are on a unix you should just be able to prefix your command with
time
On Apr 15, 2014 9:38 PM, "Chris Hough" notifications@github.com wrote:

can I ask a dumb ? as I am running into build issues. what is the timecommand you are using? where can i get that?

Reply to this email directly or view it on GitHubhttps://github.com//issues/1855#issuecomment-40554583
.

csaunders commented Apr 16, 2014

If you are on a unix you should just be able to prefix your command with
time
On Apr 15, 2014 9:38 PM, "Chris Hough" notifications@github.com wrote:

can I ask a dumb ? as I am running into build issues. what is the timecommand you are using? where can i get that?

Reply to this email directly or view it on GitHubhttps://github.com//issues/1855#issuecomment-40554583
.

@jashank

This comment has been minimized.

Show comment
Hide comment
@jashank

jashank Apr 16, 2014

Contributor

@chrishough: Strictly, Jekyll is not slow. It takes many thousands of posts to make Jekyll "slow". As has been noted before, both Liquid constructs and third-party plugins are often the major hot-spots for site builds getting very slow.

This issue revolves wholly around a particular site's configuration -- its templates, its plugins, its layouts -- and, while, yes, the lessons here are often useful for improving other sites, it's very unlikely that Jekyll itself is what's slow in your particular case, and it's well worth isolating plugins, then any uses of Liquid, to see where your issues lie.

(Yes, I know, "many thousands" is weasel words. In my experience, my Jekyll site started getting unacceptably slow, experimentally, at the ~5000 post mark. The point at which your site starts getting slow, when it's just the bare bones, entirely depends on the speed of your hardware, especially the speed of your I/O.)

((I wonder if it's time to write that performance page at long last...))

Contributor

jashank commented Apr 16, 2014

@chrishough: Strictly, Jekyll is not slow. It takes many thousands of posts to make Jekyll "slow". As has been noted before, both Liquid constructs and third-party plugins are often the major hot-spots for site builds getting very slow.

This issue revolves wholly around a particular site's configuration -- its templates, its plugins, its layouts -- and, while, yes, the lessons here are often useful for improving other sites, it's very unlikely that Jekyll itself is what's slow in your particular case, and it's well worth isolating plugins, then any uses of Liquid, to see where your issues lie.

(Yes, I know, "many thousands" is weasel words. In my experience, my Jekyll site started getting unacceptably slow, experimentally, at the ~5000 post mark. The point at which your site starts getting slow, when it's just the bare bones, entirely depends on the speed of your hardware, especially the speed of your I/O.)

((I wonder if it's time to write that performance page at long last...))

@madhur

This comment has been minimized.

Show comment
Hide comment
@madhur

madhur Apr 16, 2014

With the 5000 posts, I believe incremental generation is the way to go for Jekyll.

madhur commented Apr 16, 2014

With the 5000 posts, I believe incremental generation is the way to go for Jekyll.

@chrishough

This comment has been minimized.

Show comment
Hide comment
@chrishough

chrishough Apr 18, 2014

@jashank true, I understand that, however, are there plans for individual page regen? One of my co workers has been working with assemble.io and it can even use multiple threads to speed up generation.

@madhur +1

chrishough commented Apr 18, 2014

@jashank true, I understand that, however, are there plans for individual page regen? One of my co workers has been working with assemble.io and it can even use multiple threads to speed up generation.

@madhur +1

@troyswanson

This comment has been minimized.

Show comment
Hide comment
@troyswanson

troyswanson Apr 18, 2014

Member

@chrishough Yep, @mattr- is working on it in #1761.

Member

troyswanson commented Apr 18, 2014

@chrishough Yep, @mattr- is working on it in #1761.

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.