I measured the last releases. The major slowdown came from the new layout introduced in 1.20. This also regressed with the enums, which was fixed in the commit above. 

IMHO the only way to improve the speed again would be to review the generated docbook and see if we can simplify it while keeping the overall layout. The part that adds most seems to be that parameters are now in a table instead of a list.


git HEAD
real	1m40.949s user	1m38.250s sys	0m2.251s
real	1m40.849s user	1m37.941s sys	0m2.646s
real	1m40.576s user	1m37.493s sys	0m2.806s

1.22 (broken)
----  --------- ----  --------- --- --------

1.21
real	1m36.665s user	1m33.840s sys	0m2.752s
real	1m36.679s user	1m33.918s sys	0m2.708s
real	1m37.103s user	1m34.382s sys	0m2.502s

1.20

real	1m37.202s user	1m34.175s sys	0m2.752s
real	1m38.080s user	1m35.153s sys	0m2.701s
real	1m38.246s user	1m35.479s sys	0m2.506s

1.19

real	1m27.872s user	1m24.796s sys	0m2.779s
real	1m27.640s user	1m24.525s sys	0m2.889s
real	1m27.041s user	1m24.272s sys	0m2.611s

The patch in #742404 will give us some speed back.

real	1m34.871s user	1m32.274s sys	0m2.497s
real	1m34.717s user	1m32.043s sys	0m2.612s
real	1m34.295s user	1m31.463s sys	0m2.786s

Building the GTK+ documentation takes much longer than before.

I didn't investigate the culprit commit, but it's a recent commit.

I use gtk-doc master, currently commit 1baf9a6.

My config:

gtk-doc was configured with the following options:
==================================================
configure: ** Python based tools enabled, using /usr/bin/python
configure:    XML PDF support disabled, no dblatex or fop available
configure: ** Syntax highlighting of examples enabled, using /usr/bin/source-highlight
configure: ** Building regression tests
configure:    Debug tracing disabled
configure: ** Documentation enabled

Sébastien, what is *before*? Did you run the latest release before. There aren't many recent commits. So if I get some anchor, I can bisect.

"before" was somewhere between 1.24 and 1.25. With support for the new entities feature containing PACKAGE variables. So for example at commit ca106ec.

With git master it's also slower for other projects, not just gtk+.

For GtkSourceView there is not a big difference between commit ca106ec and git master: 25s vs 31s.

But for GTK+ I think there is a bigger difference.

Mmmh, gtk-doc at commit ca106ec is also quite slow with gtk+ master. IIRC it was possible to build the gtk+ docs in less than roughly 20 minutes on my computer. Now it seems to take forever. So it's probably some changes in gtk+ that slows down the docs build as well, not just gtk-doc changes.

But I think at the time of GTK+ 3.18 or 3.16 for sure, building the GTK+ docs - with the corresponding gtk-doc version at that time - was much faster.

'make' in gtk+/docs/reference/gtk/:

with gtk-doc master:
real    127m38.957s
user    127m27.617s
sys     0m5.315s

with gtk-doc at commit ca106ec:
real    133m46.216s
user    133m28.480s
sys     0m4.873s

So the regression must be before commit ca106ec, or something has changed in gtk+.

The only solution for this is to drop the xsltproc + docbook-xslt tool chain. I am working on a prototype in git.

I'll close this. gtkdoc-mkhtml2 is shaping up nicely (much faster) and will come. We don't need to keep the bug open for this though.

(In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #9)
> gtkdoc-mkhtml2 is shaping up nicely (much faster) and will come.

Does it mean that the binary is renamed now/will be renamed, or it's just a working name and it'll replace the current gtkdoc-mkhtml one day?

gtkdoc-mkhtml will replace gtkdoc-mkhtml + gtkdoc-fixxref. I'll try to keep the parameters a similar as it makes sense, so that switching is easy.

I will provide alternative makefiles. For people using cmake, we need to update the build rules. The biggest advantage of mkhtml2 are:
* speed: building gtk3 docs goes from 3:46 min -> 20 sec
* portability: only a handful of python modules required (anytree lxml pygments) instead of the docbook xslt toolchain

If people are happy with the new toolchain, I'd like to drop the old one at some point.

(In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #11)
> gtkdoc-mkhtml will replace gtkdoc-mkhtml + gtkdoc-fixxref. I'll try to keep
> the parameters a similar as it makes sense, so that switching is easy.

Okay, good. Ideally make it easy to distinguish which gtk-doc version is used, thus I can update my scripts as well. I do not want to bump the gtk-doc dependency at the moment.

(In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #11)
> * speed: building gtk3 docs goes from 3:46 min -> 20 sec

Wow, awesome!

With mkhtml2 how to write additional pages of documentation? For example an introduction to the library, a porting guide, etc. Currently those are written in docbook. Will docbook still be supported? Or do the docbook pages need to be re-written in another format, e.g. markdown?

I'll write an email to the desktop-devel/gtkdoc list soon. Still trying to make the new tool more complete. The new tool still supports docbook, it is basically a drop in replacement. 
To you try this on your project, simply clone gtkdoc and build it, then run e.g.

<path-to-gtkdoc-checkout>/gtkdoc-mkhtml2 glib glib-docs.xml; 

This will generate docs in a dif called 'db2html' for the time being to not conflict with html docs.

If you want to diff then run
<path-to-gtkdoc-checkout>/tools/c10e-html.py html
<path-to-gtkdoc-checkout>/tools/c10e-html.py db2html
meld html db2html

The c10e-html.py reindents the html and strips a few things to make the delta smaller. There still will be some delta, please look at the comments at the head of gtkdoc/mkhtml2.py. 

If you get warnings like:
mkhtml2.py:convert__unknown:370:WARNING:Add tag converter for "figure"
thats about docbook tags that I don't handle yet. If you'd ike to help, definitely talk to me on #gtkdoc to make sure I don't overlook patches and we're not duplicating work.

Ok great, I'll try when I have the time.