Skip to content
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

RFC: lazy-load items #3

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions active/0000-lazy-load-items.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
= Lazy-load items
:start_date: 2016-01-03
:rfc_issue: (leave this empty)
:nanoc_issue: (leave this empty)

== Summary

Do not load all items into memory, but compile them one-by-one.

== Motivation

* Loading all items in memory is problematic in terms of memory pressure. For large sites, Nanoc can run out of memory, or spend a large amount of time in the garbage collector footnote:[CRuby 2.2 has a generational garbage collector, which helps alleviate this problem. I have not compared performance of CRuby 2.1 and 2.2 in terms of GC performance yet, however.].

* Loading items one-by-one allows compilation to start right away, rather than waiting for all data to have been loaded into memory. With data sources that pre-fetch data, I/O wait time could be reduced to a minimum. This approach will also get us a step closer towards parallelism footnote:[CRuby’s global interpreter lock will prevent us from gaining much here, but it will benefit other Ruby implementations that do not have such a lock, such as JRuby.].

== Detailed design

This depends on letting data sources find objects. For details, see https://github.com/nanoc/rfcs/pull/1[RFC #1].

(wip)

== Drawbacks

(wip)

== Alternatives

* Rather than lazy-loading items, load all items into memory but lazy-load their content and attributes instead. This likely will not give much of a performance gain (if any at all), since the content and attributes for each item needs to be loaded at some point anyway, in order for the checksum to be calculated.
+
To get around this problem, at the end of compilation, the previous checksum of an item could be reused if neither their content nor attributes were loaded.

== Unresolved questions

(wip)