Docpad - how can I find out why it is slow?

I port my tumblr blog to docpad and started with this template: https://github.com/ervwalter/ewalnet-docpad

Now my problem is that "docpad run" takes 58 seconds to start, and starting in left mode takes 23 seconds. I wrote the author of this template, and he says that he has the same thing, but he does not bother him too much.

But I don’t want to wait half a minute for every change in the blog to see what it looks like, so I'm trying to make it faster. I tried profiling with nodetime, but I don’t see the granularity by the method or so. My assumption is that time is wasted in partial, while whole messages are sent in partial

How can I profile Docpad to see where time is wasted? I know that the question is very broad, but all I found when optimizing performance on DocPad is that you should force Docpad not to analyze static files.

Update the missing link was that I needed to run the CPU profiler on nodetime:

  • configure nodetime described here
  • start CPU profiler on nodetime
  • start docpad: docpad --profile run

Unfortunately, in my case, the output does not help much. The results of my launch show that 81% of the time is spent in ambi.js , which seems to be just an intermediate level that calls functions. I could not find out what functions are calling by adding console.log(fireMethod.toString()) , I only see

 function () { [native code] } 

so I'm not much further. How can I find out where the time is actually spent? For reference: here is my v8.log

Also, I'm a little worried that docpad almost only relies on modules written by Benjamin Lupton. Why is this so?

+6
source share
2 answers

After an odyssey for about 1 week, I came to the conclusion that Docpad is not designed for speed, it is designed to handle complex sites. Some facts:

  • even a new docpad installation with only bootable twitter download takes 12 seconds to build
  • there is no means to restore files whose source files have been changed (dependency tree), it always restores everything
  • reading streams such as this shows that speed is out of focus

My use case is to write articles for a blog, and I have a lot of "change the text and see how it looks." I switched to Hexo, which is much faster:

  • hexo server starts in 2.5 seconds. When livereload enabled livereload when changing a blog entry, the broswer tab reloads the page and displays the new content in about 1 second
  • generating all files again with hexo clean and hexo generate takes only 5 seconds.

This is the same setup (with less , coffeescript , etc.) that I used for DocPad, where DocPad took 38 seconds to run.

In addition to speed, hexo gave me

  • themes : hexo perfectly separates the theme and content (DocPad mixes the two). There are currently about 30 hexo themes to choose from
  • read more implementation : in hexo <! --more --> <! --more --> supported out of the box
  • deployment on github pages is outside the Architecture field
  • it was much easier for me to understand, writing widgets is bliss, the documentation also looks nicer

In general, hexo seems to be better suited for blogs, while docpad is better suited for more complex sites. Hexo looks like he is taking off, gaining about 30 stars on github per week, while docpad gets about 10 stars per week.

+2
source

you can use meta p>

autonomous: true

while working on a file. This meta will only restore this file if it updates it. Delete the meta after completion.

0
source

Source: https://habr.com/ru/post/969849/


All Articles