3 ms·

> Unless your software is intended to reload blog posts live like Hugo/Jekyll/other static site generators This falls into this? > But for code that’s on the

by _gabe_ 4y ago

> Unless your software is intended to reload blog posts live like Hugo/Jekyll/other static site generators This falls into this? > But for code that’s on the critical path of a service back-end running on a big sharded fleet with lots of zeroes in the “per second” numbers A static site generator is a simple utility that should take 100ms at most on a modern crappy laptop. It's not some backend service that's in a critical path, but it's also not a difficult engineering task. Parse input, produce output. This isn't something that should take seconds, which I think is what the OP was getting at. But because of the language choices made, and the millions of lines of bloated code, it does take seconds.

Jtsummers 4y ago
Yes. Maybe not directly, but more like it versus a one-off "I just made a new blog post and can wait 10 seconds for it to render and deploy." If you're reloading the blog posts live then you're on the critical path, not a one-off anymore. So you need to think about performance. In the former case, the performance really doesn't matter. If you've got a personal blog, does it matter if your update takes 10 seconds or 1 second? Probably not, if it does it's the most important blog in the world. If you've got customers with many blogs and need to take their updates and render them, then the performance matters because it's shifted from 1 to many (hundreds? thousands?). And now that 10 second delay is a big issue, you're either using a fleet of servers to handle the load or some customers don't see updates for days (oops).
- kennywinker 4y ago
  This sounds like a "using a screwdriver to drive a nail" problem. Jekyll is designed to be run by the end-user, so it's not optimized for fast build times. Its design goals don't prioritize performant builds, because most people don't care if it takes 30s to update their blog. If you decided to deploy a tool that's designed to be run infrequently, and in a non-time-sensitive way, on a centralized service - it's up to you to make it fast or parallelize it (e.g. github pages). Trying to say that some piece of software is badly written or designed because it can't be used in a way it's not designed to be used, just seems silly. If I use `grep` to do realtime audio processing, I'm probably going to have a bad time.
  - anonymoushn 4y ago
    Calling people end users doesn't make it acceptable to waste their time.
  - Jtsummers 4y ago
    Right, I also misconstrued the original commenter as suggesting using it for many people when I realized (after my previous comment) they meant for one user. However, they still are describing moving rendering some kind of markup to HTML to the critical path with live reloading. In that case, performance is absolutely critical (as stated in the initial article too) because, well, it's on the critical path. A 10 second delay in a "live reloading" situation (suppose a two pane view with markup on the left and rendered HTML on the right) would become intolerable if every character change resulted in that kind of delay. So yes, in that case something that can render it faster would be better. But if it's just a personal blog? Who cares if it takes 10 seconds or 1 second unless it's rendering many people's blogs? In which case it would, again, be moved to the system's critical path as a blog hosting service.
  - jcelerier 4y ago
    I don't understand this at all, this frustrate some to no end with Jekyll - I would be much more productive if I didn't have to wait 20 seconds between each edit to check that the figure is at the right place
- _gabe_ 4y ago
  > In the former case, the performance really doesn't matter. If you've got a personal blog, does it matter if your update takes 10 seconds or 1 second? It shouldn't matter, but the fact that you framed the question as 1 second in the fast case shows that this does matter haha. The fast case in this scenario should be under 10ms, and the slow case should be half a second. It shouldn't take anywhere near 1 second to generate a static site! A modern low end CPU can process upwards of 40GB/s of data. The last time I checked, the entire set of encyclopedia Brittanica is only around 1 GB. I don't know many blogs that approach that much information. At most, a blog probably only has around a few tens of Kilobytes of actual text. It should never take more than a second to process that, but it often takes upwards of 30 seconds to several minutes. This is what I was trying to emphasize before haha. Even if code isn't in the critical path, there's no reason it should take several seconds to do almost anything, unless it involves communicating over a network. We can stream audio/video data over a network in real time on low end computers through Zoom. That's gotta be processing several MB of information at least every second in real time. If we can do that, surely we should be able to build a static site generator that can generate any blog in under a second, right?

by _gabe_ 4y ago

Jtsummers 4y ago

Yes. Maybe not directly, but more like it versus a one-off "I just made a new blog post and can wait 10 seconds for it to render and deploy." If you're reloading the blog posts live then you're on the critical path, not a one-off anymore. So you need to think about performance. In the former case, the performance really doesn't matter. If you've got a personal blog, does it matter if your update takes 10 seconds or 1 second? Probably not, if it does it's the most important blog in the world. If you've got customers with many blogs and need to take their updates and render them, then the performance matters because it's shifted from 1 to many (hundreds? thousands?). And now that 10 second delay is a big issue, you're either using a fleet of servers to handle the load or some customers don't see updates for days (oops).

kennywinker 4y ago
This sounds like a "using a screwdriver to drive a nail" problem. Jekyll is designed to be run by the end-user, so it's not optimized for fast build times. Its design goals don't prioritize performant builds, because most people don't care if it takes 30s to update their blog. If you decided to deploy a tool that's designed to be run infrequently, and in a non-time-sensitive way, on a centralized service - it's up to you to make it fast or parallelize it (e.g. github pages). Trying to say that some piece of software is badly written or designed because it can't be used in a way it's not designed to be used, just seems silly. If I use `grep` to do realtime audio processing, I'm probably going to have a bad time.
- anonymoushn 4y ago
  Calling people end users doesn't make it acceptable to waste their time.
- Jtsummers 4y ago
  Right, I also misconstrued the original commenter as suggesting using it for many people when I realized (after my previous comment) they meant for one user. However, they still are describing moving rendering some kind of markup to HTML to the critical path with live reloading. In that case, performance is absolutely critical (as stated in the initial article too) because, well, it's on the critical path. A 10 second delay in a "live reloading" situation (suppose a two pane view with markup on the left and rendered HTML on the right) would become intolerable if every character change resulted in that kind of delay. So yes, in that case something that can render it faster would be better. But if it's just a personal blog? Who cares if it takes 10 seconds or 1 second unless it's rendering many people's blogs? In which case it would, again, be moved to the system's critical path as a blog hosting service.
- jcelerier 4y ago
  I don't understand this at all, this frustrate some to no end with Jekyll - I would be much more productive if I didn't have to wait 20 seconds between each edit to check that the figure is at the right place
_gabe_ 4y ago
> In the former case, the performance really doesn't matter. If you've got a personal blog, does it matter if your update takes 10 seconds or 1 second? It shouldn't matter, but the fact that you framed the question as 1 second in the fast case shows that this does matter haha. The fast case in this scenario should be under 10ms, and the slow case should be half a second. It shouldn't take anywhere near 1 second to generate a static site! A modern low end CPU can process upwards of 40GB/s of data. The last time I checked, the entire set of encyclopedia Brittanica is only around 1 GB. I don't know many blogs that approach that much information. At most, a blog probably only has around a few tens of Kilobytes of actual text. It should never take more than a second to process that, but it often takes upwards of 30 seconds to several minutes. This is what I was trying to emphasize before haha. Even if code isn't in the critical path, there's no reason it should take several seconds to do almost anything, unless it involves communicating over a network. We can stream audio/video data over a network in real time on low end computers through Zoom. That's gotta be processing several MB of information at least every second in real time. If we can do that, surely we should be able to build a static site generator that can generate any blog in under a second, right?