Symphony.

After seeing some large projects, I've realised just how slow the debug page's syntax highlighting code is. Slowness bothers me muchly, so I decided to fix it, along with a related bug and even some unnoticed bugs like incorrect comment/CDATA highlighting. This fix will be in the upcoming beta, but I'm making it available now in case it might help relieve stress for anyone working on large sites. (Upload the attached admin.js to /symphony/assets/.)

There are more debug page speed improvements on the way; this just fixes the syntax highlighting part. But it's noticeably faster - between 2x and 10x, depending on your browser - due to greatly reducing the number of regex passes required.

Cool. Thanks Scott. Faster is (almost) always good ;)

Thanks Scott. I was waiting up to 60 seconds in Firefox for couple pages but now they appear to load in around 30 seconds.

Here's also a quick way to improve your speeds. Use Safari (Windows or Mac).

@Lewis:

I was waiting up to 60 seconds in Firefox for couple pages but now they appear to load in around 30 seconds.

Yikes. That's motivation enough for me to complete the other speed improvements. I'm guessing you probably have lots of utilities attached to those pages. I've just updated the attached code so that it only performs syntax highlighting on a code block when it's asked for, and I think this should greatly improve response times for you.

Of interest, we even looked into generating the syntax highlighting using XSLT, but realised this would have been equally as slow.

Why not just use php (GeSHi) to do it.

The original suggestion

@ibolmo: We did strongly consider this, and I respect the suggestion, but it turns out there are some benefits of putting this logic in the JS. We may still end up using PHP/XSLT instead, but for now this looks like the better approach.

1. Theoretically, the debug page should load fastest (from request to interaction) when the JS employs the technique of only highlighting a code block when it's brought into view. This is especially true when there are lots of utilities on that page.
2. In order to perform XPath operations, the JS needs the full unencoded document content to build its own DOM tree. I'm still not sure whether XPath highlighting will be possible, and if not, this would lessen the need for JS-based highlighting.
3. The JS (as of RC1) already has the infrastructure to let extensions provide replacement syntax highlighting, remove it completely, or add functionality like code folding.

Has anyone else encountered errors when using the new 'admin.js' file? I haven't tested this in other browsers / other installs yet, but in FireFox2/Mac my debug data is being truncated at about 134 lines. Changing back to the original file fixes it. Hmm...

I should do more thorough testing. Now it's fixed, download from above.

The curious bug that caused this was Firefox splitting anything beyond a certain character length into multiple text nodes, which is totally compliant with the spec, I just didn't happen to know about this behaviour.

Thanks Scott!