英文:
How does Hugo maintain site-wide data, like .Site.AllPages?
问题
我正在寻找一些关于Hugo如何管理整个网站数据的简短示例，比如Site.AllPages。
具体来说，Hugo似乎读取每个文件及其元数据之前就开始生成页面，并使得.Site.AllPages等内容可用，这似乎太快了，但显然这是必须的。
Ruby（Jekyll）和Python（Pelican）真的如此慢吗，还是Hugo在生成页面之前采用了某种特定的（算法）方法来准备一切？
英文:
I'm looking for some bite-sized examples on how Hugo might be managing site-wide data, like Site.AllPages.
Specifically, Hugo seems too fast to be reading in every file and it's metadata, before beginning to generate pages and making things like .Site.AllPages available -- but obviously that has to be the case.
Are Ruby (Jekyll) and Python (Pelican) really just that slow, or is there some specific (algorithmic) method that Hugo employs to generate pages before everything is ready?
答案1
得分: 4
没有什么魔法，Hugo在.Site.Pages等集合填充并准备好之前不会开始任何渲染。
以下是一些关键点：
- 我们有一个处理流程，在可能的情况下进行并发处理，所以你的CPU应该会很忙。
- 每当我们进行内容操作（短代码、表情等），你很可能会看到一个手工编写的解析器或为了提高速度而构建的替换函数。
- 我们非常关注“快速”这一点，所以我们有一套可靠的基准测试来检测任何性能退化。
- Hugo是用
Go构建的，Go非常快速，并且有一套非常出色的工具（pprof、基准测试支持等）。
以下是使hugo server变体比常规的hugo构建更快的一些其他要点：
- Hugo使用虚拟文件系统，在服务器/开发模式下直接渲染到内存中。
- 我们在其中有一些部分重新加载逻辑。因此，即使我们每次都重新渲染所有内容，我们也会尝试仅重新加载和重建已更改的内容文件，并且如果是内容更改，我们不会重新加载/重建模板等。
我是GitHub上的bep，也是Hugo的主要开发者。
英文:
There is no magic, and Hugo does not start any rendering until the .Site.Pages etc. collections are filled and ready.
Some key points here:
- We have a processing pipeline where we do concurrent processing whenever we can, so your CPUs should be pretty busy.
- Whenever we do content manipulation (shortcodes, emojis etc.), you will most likely see a hand crafted parser or replacement function that is built for speed.
- We really care about the "being fast" part, so we have a solid set of benchmarks to reveal any performance regressions.
- Hugo is built with
Go-- which is really fast, and have a really great set of tools for this (pprof, benchmark support etc.)
Some other points that makes the hugo server variant even faster than the regular hugo build:
- Hugo uses a virtual file system, and we render directly to memory when in server/development mode.
- We have some partial reloading logic in there. So, even if we render everything every time, we try to reload and rebuild only the content files that have changed and we don't reload/rebuild templates if it is a content change etc.
I'm bep on GitHub, the main developer on Hugo.
答案2
得分: 1
你可以在hugolib/page_collections.go中看到AllPages。
通过git blame可以看到，它在2016年9月为了修复Hugo v0.18中的PR 2297 Fix Node vs Page而进行了修改。
该PR引用了讨论/改进提案“Node improvements”。
一旦我们同意一个页面只是一个页面，一个节点只是带有鉴别器的页面，大部分的“问题”都会变得更容易解决...
所以：
- 当前的页面是带有鉴别器“page”的页面
- 主页是带有鉴别器“home”或其他的页面
- 分类是带有鉴别器“taxonomy”的页面
- ...
它们在结构上有一些差异（分页等），但基本上它们只是页面。
有了这个想法，我们可以将它们全部放在一个集合中，并在鉴别器上添加查询过滤器：
.Site.Pages：通过鉴别器过滤为'page'*.Site.All：没有过滤器where：当序列是页面时，添加鉴别器为'page'，但允许用户覆盖
这个键（鉴别器）可以快速检索到所有的'pages'。
英文:
You can see AllPages in hugolib/page_collections.go.
A git blame shows that it was modified in Sept. 2016 for Hugo v0.18 in commit 698b994, in order to fix PR 2297 Fix Node vs Page.
That PR references the discussion/improvement proposal "Node improvements"
> Most of the "problems" with this gets much easier once we agree that a page is just a page that is just a ... page...
> And that a Node is just a Page with a discriminator.
> So:
> - Today's pages are Page with discriminator "page"
- Homepage is Page with discriminator "home" or whatever
- Taxonomies are Pages with discriminator "taxonomy"
- ...
> They have some structural differences (pagination etc.), but they are basically just pages.
> With that in mind we can put them all in one collection and add query filters on discriminator:
> - .Site.Pages: filtered by discriminator = 'page'
*.Site.All: No filter
where: when the sequence is Pages add discriminator = 'page', but let user override
That key (the discriminator) allows to retrieve quickly all 'pages'.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论