Re: [xslt] Windows build



Hi there,

> Igor,
>
>   I truly envy your knowledge and experience with Windoze (someday
> you must tell me how you have immunized yourself against all those
> viruses....), but on a number of occassions you have made mention
> of compilation times, always stressing how Windoze is fast and
> Linux is slow, e.g.

Thanx for the flowers :-)

Still, I never said anything about the speed of the operating system or its
tools, just about the time needed to compile libxml.

>   Could you give me some idea of what are the times you are
> experiencing, and why you would "expect" them to be faster than on
> Linux?  I have never attempted subjecting libxml2 to the Windoze
> compiling experience, but for Linux I get:
>
> billrouter libxml2-2.4.24 # make distclean > /dev/null 2>&1
> billrouter libxml2-2.4.24 # date;./configure>/dev/null
> 2>&1;date;make>/dev/null 2>&1;date
> Mon Sep 30 23:40:37 HKT 2002
> Mon Sep 30 23:40:46 HKT 2002
> Mon Sep 30 23:42:18 HKT 2002
> billrouter libxml2-2.4.24 #
>
> i.e. 9 seconds to configure, 1 minute 32 seconds to compile & test
> both static and dynamic libraries (latest utilities, gcc 3.1.1).

I never measured the time needed, so I cannot give you seconds. The numbers
you provide seem reasonable. The whole thing lasts longer here, but my
processor ticks at 350Mhz, which is low-end today, even if I have two of
them in this box. My claim that compilation lasts longer on Linux is based
on what I can measure with human senses, not on actual computer-based
profiling.

I do not expect the time on Linux to be any shorter. It is normal. That
Windows needs less time to build libxml is also normal, read on for the
details :-)

Configure needs a lot longer on Linux because it is a totally different
configure. My configuration process on Windows simply executes a script,
changes few files and that was it. Linux configure must check for myriad of
things, test for the presence of many functions and evaluate the contents of
many files. It has a *lot* more to do. It is only natural that it needs more
time for that.

The compilation lasts longer because the GCC on Linux must evaluate GLIBC
headers, which are a lot more complicated than those in MS C-runtime. The
nature of the two runtimes is different. MSVCRT does not make an issue out
of portability and its headers contain mostly just the function prototypes
and few macros. GLIBC is written so it can run on almost any processor
architecture and cooperate with more than one OS kernel. That this makes
GLIBC headers more complicated than those in MSVCRT is perfectly normal.

It is not the speed of actual tools that makes the difference. I have no
idea which of these tools are faster when run against the same input and the
difference will probably be small enough so only a computer can measure it.
In the case of libxml, Linux tools have a whole load of work to acomplish,
while Windows tools must do only a fraction of that.

Ciao
Igor




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]