[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: [docbook-apps] Small!! Lightweight!! xslt processorwhi

• From: =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= <olga.kryzhanovska@gmail.com>
• To: Michael Kay <mike@saxonica.com>
• Date: Sat, 18 Aug 2012 00:44:01 +0200

An issue I noticed is the efficiency of memory allocations. A lot of
applications *reserve* far more memory than they actually use.
xsltproc for example uses only 40-50MB when doing Docbook
transformations but the swap reservation reported by the Solaris proc
tools reports around 200MB reserved. I wish
https://mailman.research.att.com/pipermail/ast-developers/2012q3/date.html
would not be weeks behind the actual state of the list, there was a
recent comment about allocator efficiency, comparing
glibc/jemalloc/AST valloc.

I also wish that people would not bash people around if some one
complains about resource usage, it would be at least nice to think
about it, and look for improvements, before packing out the big clubs
and make fun out of people.

Finally, IMO a light version of xslt processing would be *very*
welcome. I have been experimenting with moving an old code base with
nroff documentation to Docbook/XML, but found myself in the situation
that many platforms do not support Docbook/XML as input for
/usr/bin/man and thus *must* have the nroff versions (those we want to
get rid of). The solution would be Docbook/XML to nroff,  but the only
known way is using a xslt style sheet, which raises the issue of
xsltproc being to fat for standalone operations.
I am talking about UWIN, which is a standalone POSIX/Unix environment
for Windows, which is supposed to be one, self contained, single
source archive. Putting xsltproc in there has been quite an effort,
and as result *doubled* the size of the whole source archive.
Or have it shorter: The xsltproc processor, with dependencies, is as
large as a whole POSIX/Unix environment for Windows, sans X11 of
course. This feels wrong.

Olga

On Sat, Aug 18, 2012 at 12:12 AM, Michael Kay <mike@saxonica.com> wrote:
>>IT was once done with 4MB machines, doing the same with today's machines
>> and XML/XSLT goes up to 400MB as minimum.
>
> I don't think this is something specific to XML and XSLT. Memory is so cheap
> nowadays there is very little pressure or incentive to keep things small.
> The JDK grows and grows because people want more functionality more than
> they want a smaller footprint.
>
> Having said that, I suspect that one can parse and transform a small
> document using quite a bit less than 400Mb of memory - though I can't say
> I've tried it recently.
>
> Michael Kay
> Saxonica
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>



-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----'-/`-/     olga.kryzhanovska@gmail.com   \-`\-'----.
 `'-..-| /       http://twitter.com/fleyta     \ |-..-'`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`

• Follow-Ups:
  • Re: Re: [docbook-apps] Small!! Lightweight!! xsltprocessor which is standalone!! and runs Docbook/XSL stylesheets?
    • From: Liam R E Quin <liam@w3.org>

• References:
  • Re: [docbook-apps] Small!! Lightweight!! xslt processor which isstandalone!! and runs Docbook/XSL stylesheets?
    • From: Dan Shelton <dan.f.shelton@gmail.com>
  • Re: Re: [docbook-apps] Small!! Lightweight!! xslt processorwhich is standalone!! and runs Docbook/XSL stylesheets?
    • From: Michael Kay <mike@saxonica.com>