超过 8000 篇的文章 Hexo 无法生成了……

[libasten]

至少卡了五分钟了，不想等了，估计文章数超过 5000 的就很慢了。
机器配置是 ssd 加 i5 7500 的台式机，
我估计可能也很少有个人博客超过 5000 文章的吧？
我观察过网上很多 hexo 的用户，文章数超过 500 的都没见过，可能 hexo 的使用场景就是 1000 以内的博客吧，超过一定数量的，还得上有数据库的 cms ？
不知道大家怎么看？

[putaozhenhaochi]

兄弟 人的精力是有限的。
月光博客那么高产 说明写了很多垃圾 /doge

[whypool]

这么多不考虑动态？

[cnrting]

hexo 这个东西只适合小打小闹谈情怀

[isukkaw]

你好，我是 Hexo 核心团队成员。请您在 GitHub hexojs/hexo 上新建一个 issue 好么？我们会帮你一步一步 debug 性能瓶颈问题。

[isukkaw]

@Kobayashi #6 Hexo 过去一年做了一堆性能优化，我们的 Benchmark 数据是 300 篇文章 15s，1000 篇文章 45s 。
@leimao #7 Node.js 的线程间通信性能太差。我们试过某些操作上多线程，结果性能更差了。
@whenov #13 Hexo 各项数据高度耦合，你如果修改了一篇文章，那么是不是目录页面也要重新渲染？分类页面和标签目录也要重新渲染？ RSS 也要重新生成？ Hexo 已经尽可能做了差分渲染了，但是效果并不好。

[lights]

看到楼上 Hexo 核心成员，惊讶于 V 站卧虎藏龙，好多大佬

不过我昨天和今天才把 GitHub Pages 从 Hexo 切换到 Hugo
（我博客文章很少，只是看中了 Hugo 的一个 Github style 主题）

Hugo 的第三方教程少很多，但是编译速度极快，而且服务启动后可以做到一边写一边在浏览器预览编译结果

[Hello0World]

v 站藏龙卧虎

[ArJun]

hugo 是未来

[axihe]

Hexo 模式非常坑的，Hexo 是那种全部准备完事后再开始输出数据的，不是 Gulp，Hugo 那种流输出模式；
推荐用 Hugo 吧，Hugo 主题虽说远没有 Hexo 丰富，但是看下语法，移植过来写起来也还好的；
Hexo 你能搞到 5000 很不错了，说明文章和文章之间的耦合不严重；如果耦合严重的，到 1000 就尿了；

[isukkaw]

@lights #26 Hexo 也可以起 Server 一边写一边预览
@axihe #29 不是 Stream 或者背压的问题，Hexo 组织了一个数据结构（会被存在内存里），然后所有操作（包括插件 API ）都是在内存里完成，最后再把生成的结果写入硬盘。
Hexo 的差分渲染就是这么做的：检查哪些文件的最后更改日期发生改变、读取这些文件、然后重新跑一次 process 、两个数据 diff 一下，最后把发生更改的文件写入硬盘。
IO 从来不是瓶颈，Hexo 的性能瓶颈在于插件 API 。

[PbCopy111]

我觉得最后不管写什么，都会回到 wordpress 的怀抱。。。

[lxml]

看好 vue 周边项目 vitepress

[cmdOptionKana]

全球工单网站名不虚传

[isukkaw]

@PbCopy111 #31 WordPress 这种动态站点化整为零，用户访问一次服务端渲染一次，节省了预先生成的时间、适合大型站点，但是非常脆弱。
@lxml #32 这我敢打包票，同样 300 篇文章 vitepress 做博客框架速度绝对比不过 Hexo，因为 Hexo 只操作纯字符串。而且 vitepress 对标的是 Gatsby，也不是 Hexo 。

[lisongee]

狗屁不通文章生成器？

[grimpil]

@lleon 要是让一天 1000 首诗那位来写，8000 篇也用不了多久

[seki]

你考虑得有点远了，先用着，碰到瓶颈再换啊

[xd314697475]

hugo +1
确实很快，而且操作简单

[banxiaobu]

来来来，捧上你的博客链接吧，我想观摩一下 8000 篇的博客是啥样

[oliverchen]

@PbCopy111 #31 我的路径就是 wordpress -> octopress -> hexo -> ghost -> hugo -> gatsby -> wordpress