Here’s the thread:
https://intfiction.org/t/inform-7-6l-windows-ide-slow/6814/1
The upshot of that thread seemed to be that Windows is horribly slow at writing files. Or, at least, slow enough that when you do thousands of fprintf() calls to construct a large file, you suffer. I have heard this in other contexts as well.
(For those who want to delve, it’s the debug_file_printf() function in files.c.)
Is there a way to compile the Windows version of I6 with better stdio functions? Bigger buffer, something, I don’t know?
Thanks DavidC, I’ve read the thread. Still in the new version you can turn off the debug stuff with a checkbox. And the problem isn’t fixed by that. Do you still experience the same problem?
Ah, checking the task manager I saw that windows defender goes to 50% of the CPU when the compiler is running. Turning of real time protection in windows defender fixes the problem. 
That’s weird. Why is Defender mucking with things? (rhetorical)
I had the same problem on Windows 7 using Windows Defender and Norton. My game would take an age to compile.
https://intfiction.org/t/inform-7-and-security-software/8895/1
For some reason, security software just doesn’t seem to like Inform 7.
I wonder if code-signing would allow Defender to ignore it.
This is definitely Windows Defender. When I turn off real-time protection, my Cloak of Darkness compiles instantly. With it turned on, it takes about 20 seconds.
So I added inform7.exe, inform6.exe, cBlorb.exe, ni.exe, and intest.exe as process exclusions. If course I’m telling the whole world this is an open vector for attacking my computer, but I7 compiles instantly now.
2 Likes
Well, interactive fiction can be very dangerous…
1 Like
It appears that Windows Defender is slowing down the generation of the index HTML files - it takes ages to scan each one, and succeeds in blocking the ni process until it has done each. The only solution I can see is to manually add ni.exe to the list of excluded processes.
Or comment out “Release along with source text.” until you need it.
Or change the IDE to offload the html creation to a second thread and allow the IDE to show “busy” when creating the Index.
Well, adding an exclusion to Win Defender solved the problem for me.
Guys, I’m doing my usual collation for telling Emily and I’m a bit divided on this thread.
There’s an issue here, and it’s real, and having to forego any sort of protection in any circumstances is not a very good thing, and DavidC even suggested a way in which this could be worked around IDE-wise.
On the other hand, it’s so specific and so easily workaroundable (even if unpalatable to some - not even all! - people) that it may not be worth the trouble.
D’you guys think there’s actually a need to bring this up?
Unfortunately DavidC’s suggestion is not going to make any difference. The point is that the build process happens when ni.exe is run (by the front end), and it is this that generates HTML files for the index. Windows Defender is interfering with this via its hooks into Windows, causing the index generating part of the ni.exe code to run rather slowly, so the build process takes longer than needed. There’s no point reporting this to Emily, as there is nothing she (or Graham) can do about this. I might try a few experiments at some point, but really either Microsoft fix Windows Defender to behave itself, or we have to live with it.
I recently upgraded to Windows 10, and the hang here is bad enough for me that I thought I7 had broken. I was trying everything - load as admin, various compatibility steps - and finally found this thread by googling to see if other people had this problem.
Even if there’s nothing Emily can do, it might be worth adding some kind of warning to the documentation - “if you have Windows 10, this will be hella slow, sorry.”
Just a hunch but is part of the problem that so many of the files created have “suspicious” file extensions (something the AV software thinks might be a vector for malware)? Could “auto.inf” be created with a different extension and perhaps could the index pages be created as xml (albeit with changed content) or with some non-standard extension (could be the same content, but IDEs might need to be updated to treat the files as before)?
EDIT: I tried to hack on ni.exe with a hexeditor to experiment with the above to some extent but it did not not seem to like the changes
I’ve already tried this: it doesn’t help. The problem is the generation of .html files for the index etc. However, regardless of what they’re called, Windows Defender still notices that they’re HTML and very slowly checks them. So far there seems to be no way round this other than to manually configure Windows Defender to ignore the executables that generate the HTML.
Not knowing how Window Defender works, I’m wondering if the index files were produced more smartly, would WD check them faster? I’ve already raised this at inform7.uservoice.com/forums/57 … -very-slow
Having thousands of inline scripts and inline css makes the files very large and slow to render, but those thousands of scripts may also make WD process them slowly too. If the JS code was collected into one code block (and rewritten so that it doesn’t need to specifically invoke each individual rule or object etc) then it might make a big difference.
This would be a change for Graham of course.
1 Like