<jugglinmike>
Hopefully this won't be a problem on Macs
<jugglinmike>
bobthecow: all working now.. thanks!
<bobthecow>
it's not a problem on macs.
<bobthecow>
i've never had an issue with readline on my mac.
<jugglinmike>
ok, cool
number-six has quit [Ping timeout: 246 seconds]
<jugglinmike>
After the initial build, I'm spending ~4 seconds "Loading site data..." and ~1 second "Compiling site...". 5 Seconds is nothing to scoff at, but for my designer's sake I have to ask: is there anything I can do to optimize the "Loading site data..." step?
<jugglinmike>
I suspect it's largely site-specific, so could you tell me a bit about what nanoc is doing in that step? Maybe I can optimize based on that
<bobthecow>
how 'bout just `find content/ | wc -l` ?
<jugglinmike>
bobthecow: 346
<jugglinmike>
the directory is 2.0 MB in size
<bobthecow>
okay.
<bobthecow>
so four seconds is a bit on the long side, but not unheard of.
<bobthecow>
basically what it's doing:
<bobthecow>
finding all the files in all the data sources
<bobthecow>
deciding whether they (or any of their dependencies) have changed since the last compile
<bobthecow>
figuring out where they should be routed and how they should be compiled
<bobthecow>
deciding whether other things have changed that would require a fresh compile (i.e. new / changed layouts, changed rules, changed settings, etc)
<bobthecow>
i think that's about it.
<bobthecow>
i would imagine the longest part of that is reading all the files and calculating hashes for them to decide whether they've changed.
<bobthecow>
there are a lot of things you can do to optimize the compile part of the time it takes, but i'm not sure i know of anything specific you could do to optimize the "loading data" part.
<bobthecow>
do you have any third-party data sources?
<jugglinmike>
Yeah, I tried hard to optimize the compilation step, especially with regards to appending asset hashes as GET parameters for cache-busting
<jugglinmike>
ooh, come to think of it
<jugglinmike>
I think there might be one
<jugglinmike>
Well
<jugglinmike>
We have a "static" directory that loads binary assets
<jugglinmike>
but I think we also do something fishy with external (ie over the web) data sources
<bobthecow>
if you're doing that, there's your problem.
<bobthecow>
i used to have one of those, but i implemented Nanoc::DataSource#sync so i could compile faster :)
<jugglinmike>
the external data source isn't actually modeled as a nanoc data source
<bobthecow>
umm.
<jugglinmike>
it's a request made in some random ruby script in our `lib/` directory
<bobthecow>
oh, awesome.
<bobthecow>
called in the preprocess block?
<jugglinmike>
hmm, I'm not sure about that
<jugglinmike>
I'm grepping around for where the file is required
<jugglinmike>
because it's not encapsulated in a function--it's immediately executed when this helper file is loaded
<bobthecow>
lib files are automatically required.
<jugglinmike>
Does nanoc treat "lib/helpers_.rb"
<jugglinmike>
oh
<jugglinmike>
got it
<jugglinmike>
So it just loads the data whenever it's includes, and makes it globally available :/
<jugglinmike>
included*
<bobthecow>
wheee!
<jugglinmike>
haha
<bobthecow>
yeah, that should prolly go into a data source.
<bobthecow>
is it at least creating items with it?
<jugglinmike>
nope. Arrays
<bobthecow>
or is the site just accessing the global data whilst compiling.
<bobthecow>
ugh.
<bobthecow>
so it's not even marking the dependency graph as dirty when it changes.
<bobthecow>
you should prolly fix that.
<jugglinmike>
the good news is that I can stub it out easily (by defining empty arrays), and the site compilation time goes from 5s to 3s
<jugglinmike>
so at least I know this will yield the results I want
<jugglinmike>
in addition to being cleaner
<jugglinmike>
next step: learn how to define external data sources in Nanoc
<jugglinmike>
and wrap this EventBrite gem
<bobthecow>
and have the added bonus of actually recompiling bits of your site that depend on that data when said data changes :)
<bobthecow>
check that github data source i posted.
<bobthecow>
the basic dance is:
<jugglinmike>
oh wow! This won't be so bad
<bobthecow>
define a sync method for grabbing data from the api and squishing it into a local store of some sort. i chose a yaml file.
<jugglinmike>
.gitignore that file
<jugglinmike>
?
<bobthecow>
then define an items method that reads the yaml file and returns a list of Nanoc::Item instances
<bobthecow>
or commit, whichever.
<bobthecow>
if it's changing often, or if you can put a `nanoc sync` call into your deploy workflow somewhere and not worry about the local version, i would gitignore it.
_whitelogger has joined #nanoc
<jugglinmike>
yes
<jugglinmike>
oh, good to know about static
<bobthecow>
then you should be able to simply remove the static.rb file from lib and your site will continue to compile.
<bobthecow>
depending, of course, on whether your static.rb is compatible with the core one.
<bobthecow>
but it probably is, if it's the one that was floating around a while back.
pavelkunc1 has joined #nanoc
pavelkunc has quit [Ping timeout: 264 seconds]
pavelkunc1 has quit [Client Quit]
alerante has quit [Remote host closed the connection]