5 ms·

Fellow Jekyll refugee here. I also switched to the Makefile SSG approach for the much faster incremental rebuilds. Parallel speedup with make -j is also nice.

by sigil 9y ago

Fellow Jekyll refugee here. I also switched to the Makefile SSG approach for the much faster incremental rebuilds. Parallel speedup with make -j is also nice. My SSG is called tinysite [1] [2]. Templates are jinja2. Posts are written in markdown with Pygments highlighting for fenced code blocks. Posts also have JSON frontmatter which can #include other JSON data files, and this is where it gets Make-y: all affected pages get rebuilt when a data file changes with the help of a `gcc -M`-style file dependency scanner. I use these frontmatter "data includes" for site wide metadata and for data driven pages like post indexes. There's also a dev server so you can quickly preview changes. The biggest frustration I have with the Makefile + interpreted language approach is the slow startup time of interpreters these days. When every page requires a new interpreter process it really starts to add up, if not in incremental builds, then definitely in full rebuilds of larger sites. Some quick tests I did recently of `time $INTERPRETER -[c|e] ""`: node 6 ... 70ms ruby 2 ... 58ms python 2 ... 27ms perl 5 ... 5ms sh ... 3ms Perl compares quite favorably here, but I just can't bring myself to go back to it. I wish these other interpreters would get their startup time act together! I guess this is an argument for go / Hugo? [1] https://github.com/acg/tinysite https://github.com/acg/tinysite [2] https://github.com/acg/alangrow.com https://github.com/acg/alangrow.com

dfox 9y ago
My (nowadays totally non-updated) website is built on similar approach with make+python (but with xml+xslt, which was the technology of the day in mid-00s) and the CPython's startup time was always issue even to the point that the incremental rebuilds essentially didn't make much sense (but writing the machinery was at least a fun experiment).
charlesdaniels 9y ago
This is very impressive, and definitely more elegant than my approach. Getting make -j for free was definitely a major plus; before I started using a Python script to syntax highlight inline code, my site built in under a second... now it takes around 3. I am honestly surprised to find Python is so slow in terms of start up time. This made me wonder if it was generating / searching for .pyc files, but a quick test revealed this is not the case: sh-4.3$ ls nop.py nop.sh sh-4.3$ hexdump -C nop.py sh-4.3$ hexdump -C nop.sh sh-4.3$ time python3 nop.py real 0m0.064s user 0m0.048s sys 0m0.016s sh-4.3$ time sh nop.sh real 0m0.002s user 0m0.002s sys 0m0.000s sh-4.3$ python3 -m compileall . Listing '.'... Compiling './nop.py'... sh-4.3$ time python3 nop.py real 0m0.062s user 0m0.057s sys 0m0.004s sh-4.3$ python3 __pycache__/nop.cpython-35.pyc sh-4.3$ time python3 __pycache__/nop.cpython-35.pyc real 0m0.060s user 0m0.048s sys 0m0.012s I would add that shell can be surprisingly fast for certain tasks when used correctly. It's very easy to write slow (ba)sh code though, so most shell scripts wind up being fairly non-performent. Edit: formatting.

by sigil 9y ago

dfox 9y ago

My (nowadays totally non-updated) website is built on similar approach with make+python (but with xml+xslt, which was the technology of the day in mid-00s) and the CPython's startup time was always issue even to the point that the incremental rebuilds essentially didn't make much sense (but writing the machinery was at least a fun experiment).

charlesdaniels 9y ago

This is very impressive, and definitely more elegant than my approach. Getting make -j for free was definitely a major plus; before I started using a Python script to syntax highlight inline code, my site built in under a second... now it takes around 3. I am honestly surprised to find Python is so slow in terms of start up time. This made me wonder if it was generating / searching for .pyc files, but a quick test revealed this is not the case: sh-4.3$ ls nop.py nop.sh sh-4.3$ hexdump -C nop.py sh-4.3$ hexdump -C nop.sh sh-4.3$ time python3 nop.py real 0m0.064s user 0m0.048s sys 0m0.016s sh-4.3$ time sh nop.sh real 0m0.002s user 0m0.002s sys 0m0.000s sh-4.3$ python3 -m compileall . Listing '.'... Compiling './nop.py'... sh-4.3$ time python3 nop.py real 0m0.062s user 0m0.057s sys 0m0.004s sh-4.3$ python3 __pycache__/nop.cpython-35.pyc sh-4.3$ time python3 __pycache__/nop.cpython-35.pyc real 0m0.060s user 0m0.048s sys 0m0.012s I would add that shell can be surprisingly fast for certain tasks when used correctly. It's very easy to write slow (ba)sh code though, so most shell scripts wind up being fairly non-performent. Edit: formatting.