Hello Peter,
I fully support your plan and going to move this way.
Best regards,
Alexander
05.05.2016 04:09, Peter Eisentraut пишет:
On 5/4/16 11:08 AM, Alexander Law wrote:
As was stated in the aforementioned thread, solution 2 can be much (8x)
faster with some xslt optimizations, but I thin
Done (previous patch cleaned).
This patch optimizes XSL transformations contained in docbook-xsl (1.78.1).
Tested with 9.5.2
time make html
real1m21.989s
user1m21.392s
sys 0m0.484s
1) time make xslthtml
(before the patch)
real29m19.904s
user29m18.804s
sys 0m0.888s
2) tim
On 5/4/16 11:08 AM, Alexander Law wrote:
As was stated in the aforementioned thread, solution 2 can be much (8x)
faster with some xslt optimizations, but I think now we should outline
some roadmap before we start to prepare patches and so.
Maybe we should convert to XML with DocBook4 at first ste
Thank you!
I have some more errors written down, maybe they are worth fixing too.
Second patch is for consistency in [1].
(I think XMLValidate could be aligned with "IS VALID predicate")
Third patch is for language name teared down in [1].
It seems that root of this typo is as far as in SQL Stand
Jürgen Purtz wrote:
> Hello Alvaro,
>
> yes, character entities respectively their values must be kept (what you
> have seen is an intermediate state). We will use utf-8, so every possible
> Unicode code point can be used directly. But we use not only character
> entities, there are also parameter
On 5/4/16 10:40 AM, Alexander Law wrote:
Please have a look at the some more errors.
Regarding second patch, I think, that inconsistency should be fixed by
omitting '_name', as this parameter could also include a password.
fixed
--
Peter Eisentraut http://www.2ndQuadrant.com/
Post
Alvaro,
the advantage of draft mode is smaller than 15% in the three
environments. In Docbook5 it reduces the elapsed time from 4:07 to 4:02.
Jürgen Purtz
On 04.05.2016 17:18, Alvaro Herrera wrote:
The dsl toolchain has a "make html" format which creates the index and a
"make draft" that d
Hello Alvaro,
yes, character entities respectively their values must be kept (what you
have seen is an intermediate state). We will use utf-8, so every
possible Unicode code point can be used directly. But we use not only
character entities, there are also parameter entities and external
enti
04.05.2016 19:52, Jürgen Purtz пишет:
On 04.05.2016 17:08, Alexander Law wrote:
As was stated in the aforementioned thread, solution 2 can be much
(8x) faster with some xslt optimizations, but I think now we should
outline some roadmap before we start to prepare patches and so.
Maybe we should
Jürgen Purtz wrote:
> The real challenge is the second
> step as it implies some manual modifications (entities, non-valid markup in
> sense of db5-schema) and a switch to a different output chain. Maybe we can
> live for a while with some files, which are not valid against db5-schema -
> as far a
On 04.05.2016 17:08, Alexander Law wrote:
As was stated in the aforementioned thread, solution 2 can be much
(8x) faster with some xslt optimizations, but I think now we should
outline some roadmap before we start to prepare patches and so.
Maybe we should convert to XML with DocBook4 at first
Hello Alvaro,
04.05.2016 18:21, Alvaro Herrera wrote:
Alexander Law wrote:
Hello Jürgen,
As was stated in the aforementioned thread, solution 2 can be much (8x)
faster with some xslt optimizations, but I think now we should outline some
roadmap before we start to prepare patches and so.
Can th
Alvaro Herrera writes:
> The dsl toolchain has a "make html" format which creates the index and a
> "make draft" that doesn't. You timed the former only. What's the
> timing for an equivalent of "make draft" in the xslt chain? If it
> exists and is short enough, it seems acceptable to me that t
On 04.05.2016 16:51, Tom Lane wrote:
Ouch. What about output to PDF? While we don't care as much about
that as HTML for day-to-day use, it has to be feasible (ie, not hours).
regards, tom lane
Actually I made tests using fop on single files (the converted sgml
files)
Alexander Law wrote:
> Hello Jürgen,
>
> As was stated in the aforementioned thread, solution 2 can be much (8x)
> faster with some xslt optimizations, but I think now we should outline some
> roadmap before we start to prepare patches and so.
Can the Docbook5 build be sped up with similar hacks?
Jürgen Purtz wrote:
> I measured following elapsed times on an Intel i5 processor:
>
> 1. generate all HTML files with dsl script (make html): 0:48 min.
> 2. generate all HTML files with xslt script (make xslthtml): 16:01 min.
> 3. generate all HTML files with xslt script in the new environment
>
Hello Jürgen,
As was stated in the aforementioned thread, solution 2 can be much (8x)
faster with some xslt optimizations, but I think now we should outline
some roadmap before we start to prepare patches and so.
Maybe we should convert to XML with DocBook4 at first step?
Then, once we get eve
=?UTF-8?Q?J=c3=bcrgen_Purtz?= writes:
> I measured following elapsed times on an Intel i5 processor:
> 1. generate all HTML files with dsl script (make html): 0:48 min.
> 2. generate all HTML files with xslt script (make xslthtml): 16:01 min.
> 3. generate all HTML files with xslt script in th
Hello,
I measured following elapsed times on an Intel i5 processor:
1. generate all HTML files with dsl script (make html): 0:48 min.
2. generate all HTML files with xslt script (make xslthtml): 16:01 min.
3. generate all HTML files with xslt script in the new environment
(pure Docbook5): 4:0
Hello Peter,
Thanks!
Please have a look at the some more errors.
Regarding second patch, I think, that inconsistency should be fixed by
omitting '_name', as this parameter could also include a password.
Best regards,
Alexander
04.05.2016 04:10, Peter Eisentraut пишет:
On 4/18/16 1:30 AM, A
20 matches
Mail list logo
