Markbind: Support more informative performance logging option for markbind serve

Created on 31 Jan 2020  路  4Comments  路  Source: MarkBind/markbind

Is your request related to a problem?

~It may be helpful to have some developer only code, e.g.~

  • ~print extra debug statements~ ( this should be achieved through log=DEBUG as mentioned comment )
  • ~Outputting the state of content as it is passed through the various stages in page.generate() to seperate files~
  • ~developer only front end components ( e.g. including a theme switcher on the template site to test front end changes for different themes )~
  • ~鉂攡

More informative performance logging of various stages of page generation ( preprocess/parse/... ) can help us figure which areas are the bottlenecks that could be improved on.

Describe the solution you'd like
~A separate command, such as markbind servedev can be implemented.~

~It would accept some options like -t for more detailed performance logging, -d for printing debugging statements, etc.~

A new option for markbind build / serve, eg. -p, can be implemented for this.

a-DevOps a-Performance d.easy p.Low

Most helpful comment

What kind of debugging statements were you intending to print? The logging feature should be enhanced first by allowing the level of logging to be specified in command line (e.g. markbind serve --log=DEBUG or something).

All 4 comments

What kind of debugging statements were you intending to print? The logging feature should be enhanced first by allowing the level of logging to be specified in command line (e.g. markbind serve --log=DEBUG or something).

What kind of debugging statements were you intending to print? The logging feature should be enhanced first by allowing the level of logging to be specified in command line (e.g. markbind serve --log=DEBUG or something).

Hmm, true. This should definitely be the first step.

Apologies, what I meant more for this was, for example, printing the state of the content being passed down the promise chain in page.generate() after each significant stage, then outputting it into some files. This would allow for checking the output after each stage is as intended.
Not something suitable for printing in the console at all in hindsight.

I've edited the main post to reflect it

Ok I get what you mean now, though since this is a developer feature for an existing command, I don't think we need a separate command exclusively for such a feature, a switch for developer mode for serve is sufficient (having this extra command doesn't help in not polluting the logic for site generation anyway).

  • performance logging of various stages of site generation

A built-in profiler would definitely be useful in gauging performance pain points, so I definitely see a value in it.

  • Outputting the state of content as it is passed through the various stages in page.generate() to seperate files

A debugger already allow you to examine the content though, so I am not sure whether this is inherently useful.

  • developer only front end components ( e.g. including a theme switcher on the template site to test front end changes for different themes )

This seems like a lot of work for a small bit of convenience?

  • Outputting the state of content as it is passed through the various stages in page.generate() to seperate files

A debugger already allow you to examine the content though, so I am not sure whether this is inherently useful.

  • developer only front end components ( e.g. including a theme switcher on the template site to test front end changes for different themes )

This seems like a lot of work for a small bit of convenience?

Good point, for this particular use case, perhaps this could be a seperate issue "support live reloading for theme option in site.json"

This would be valuable to both users and developers

Ok I get what you mean now, though since this is a developer feature for an existing command, I don't think we need a separate command exclusively for such a feature, a switch for developer mode for serve is sufficient (having this extra command doesn't help in not polluting the logic for site generation anyway).

A built-in profiler would definitely be useful in gauging performance pain points, so I definitely see a value in it.

馃憤
To sum, I'll rename this issue as "support performance logging option for markbind serve", if its fine!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ang-zeyu picture ang-zeyu  路  4Comments

jamos-tay picture jamos-tay  路  4Comments

le0tan picture le0tan  路  7Comments

yamgent picture yamgent  路  5Comments

damithc picture damithc  路  6Comments