The quick-fix works! Thanks zarf!
Just a couple of, potentially, rather stupid and redundant questions. What is the XML debug file for?
Debugging obviously!
But if we can just disable the -k flag while apparently not losing any vital index information that inform needs, where is it actually used? Why is the -k flag on by default? And why is the file in XML format (all on a single line)? To me, XML seems a little bit incongruous with the rest of inform.
The Inform IDE does not currently use the debug data. However, it could someday.
I’ve done a very small amount of work towards putting a debug layer into the Glulxe interpreter. It’s just a proof of concept, right now, but it successfully parses the debug data and lets the player view it interactively.
It’s in XML format because XML is the suckiest general data format except for all the others. (Okay, JSON is slightly better. I forget why we went with XML over JSON. More parsing libraries out there, I suppose.)
The old Inform debug file format was a compact binary format. It was impossible to extend and all the fields were frozen at 4 or 6 bytes. It couldn’t cope with large Glulx games. Rather than inventing a new rigid format, we went with XML. Future extensions can go in as new tags without changing the overall format.
When I get the chance, I will put some time into tracking down where the bottleneck is on Windows. I can’t promise this will be soon, though. Possibly it will be better if the next build of the Windows front-end just turns off -k for now.
Perhaps it would be worth changing to JSON before debuggers start using the format? (And I suspect Zarf is being modest when he says he’s done “a very small amount of work”…)
Two or three days. I can get glulxe/cheapglk to display a symbolicated stack dump on crash.
I don’t think JSON would be enough better to be worth rewriting all the Inform debug-writing code. Plus my two or three days of work.
This gets it down from 12s to 8s. Any tips for speeding up the NI compiler?
Buy a Mac.
Actually the 8s was with a single room. Three rooms is back up to 12s.
I don’t think buying a Mac is a reasonable response.
It wasn’t a serious response. But I am somewhat horrified by the hardware that PC vendors pass off on you people.
I did a quick test on my 2006 Mac laptop (just about the bottom end of the supported Mac range for this release). A three-room game compiles in 4.5 seconds, of which the I6 stage is 1.0 second. (Shave off 0.5 sec if I suppress debug output.) I promise you that the I6 compiler has no Mac-specific optimizations.
EDIT-ADD: Okay, I misremembered the support req – Mac I7 says it goes back to OSX 10.6.8. So older machines than 2006 should be running it(*). Point remains.
(* Although someone has reported a crash on OSX 10.6.8 so maybe this is a false hope.)
I think the best thing will be to add a check-box to the preferences dialog to control whether debug info is generated, and default it to off. I will deal with that in the next few days.
I can sometimes have 20 development tools open on this laptop and compile C# stuff all the time and it’s blazing fast.
However, it is an older laptop…I think I bought it in 2010, so maybe there’s something there. I guess I’ll try it on another laptop to see what’s up.
Maybe I7-6L makes me buy a new one. I’d hate that. (;
David
So I tried it on my work laptop (I7, 8Gb) and it runs in 4 to 5s.
Oh well. My I3 seems to need replacing finally.
It’s long overdue.