Re: XML and XSLT Praise

Colin Paul Adams wrote:

>    Peter> Ok. Another big factor with the .NET XSLT classes is that
>    Peter> they are precompiled (or "NGen'ed", in .NET-speak) into a
>    Peter> DLL. (The DLL is in .NET's Global Assembly Cache or "GAC",
>    Peter> so you could almost say it's part of the operating system.)
>    Peter> This means that using it adds almost nothing to the
>    Peter> application's compilation time, and it adds zero megabytes
>    Peter> to the application's size.
>
> Presumably you could do this with the entirety of Gobo?

Yes, you could create an EiffelStudio .NET DLL (as a precompiled library, so 
that other Eiffel .NET assemblies could use it) from the Gobo classes, and 
deploy that DLL. It has dependencies on EiffelBase (correct me if I'm wrong 
on that point), so you would have to deploy a .NET DLL for EiffelBase too, 
or else include the base library classes in the Gobo DLL.

Of course, this would only work for .NET. The application to which I added 
the XSLT capability, for example, is not .NET.

But it still wouldn't be a good solution. The resulting .NET DLL would be 
huge. As the application accessed each Gobo class, the .NET just-in-time 
compiler would kick in and compile the code it needed to run. If a large 
chunk of the Gobo XSLT code is needed at run time, then the just-in-time 
compiler would spend a very long time JIT'ing the Intermediate Language (IL) 
code the first time it was accessed. That doesn't make for a nice user 
experience.

The .NET Framework classes avoid this JITter penalty by being precompiled by 
a .NET utility called NGen, which optimises for the target machine during 
installation. We could, theoretically, do this to the Gobo .NET DLL, but I 
don't know for sure whether it works; I spent a couple of hours trying to 
NGen one of our own .NET DLLs which suffers from exactly this JIT'ing 
problem, but I didn't manage to get it working. Perseverance might pay off, 
of course.

But even if we managed to NGen the Gobo classes, the .NET framework would 
still have one final trump card in terms of performance: there's a good 
chance that it has already been loaded into memory by some other .NET 
application. It's highly unlikely that a Gobo DLL would already be in 
memory. This I suspect this wouldn't be a major problem.

- Peter