Re: Managing debug logging in complex transforms: what

On 24 March 2014 20:28, Graydon <graydon@xxxxxxxxx> wrote:
> On Mon, Mar 24, 2014 at 08:05:40PM +0000, Andrew Welch scripsit:
>> On 24 March 2014 18:42, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>> > On 24 Mar 2014, at 17:31, Eliot Kimber <ekimber@xxxxxxxxxxxx> wrote:
>> >> For whatever reason I find using interactive debugging unhelpful for
>> >> debugging XSLT processing (but I couldn't code a line of Java without it).
>> >
>> > That's my experience too, I have never been sure why the difference.
>>
>> That's interesting... I use oXygen daily and get on well with its
>> debugger - the click back feature (where you click on a node in the
>> result and it highlights the line in the xslt and context node in the
>> source xml that created it) is a killer feature (I don't know if it's
>> common or unique to oxygen).  Equally, putting break points in the
>> xslt and then clicking around the call stack to see how you got there
>> can be a quick way of diagnosing issues.
>
> That is all true and it's wonderful when it's practically available.
>
> My experience is that it simply takes too long to be useful with "real"
> (that is, the multi-thousand-template, here's a several tens of MB of
> input document, horrid conversion stylesheets I was most recently
> dealing with) input.  Two orders of magnitude slower than non-debug
> execution, and a definitive answer to "but where did it die?" could be
> had by other, if more effortful, means.

I also have the pleasure of debugging other people's 10,000+ line
spidery mess of call templates, and I've never had an issue with
speed...  I'm guessing the transform you were working already took a
long time?


-- 
Andrew Welch
http://andrewjwelch.com