finally i got around to making something which i feel is a much improved, lightweight and tweakable combo of print_r() and var_dump(). i bet 90% use-cases for these functions dump into a browser, not a text editor, so why not use everything HTML/js has to offer?
there are plenty of other alternatives (dBug, debuglib, wtUtil, krumo, kint, php dump, Debug::dump), but none that lived up to my minimalist, lightweight, configurable and non-verbose desires. dump_r is completely CSS-styled, plus there are additional classes added that can usefully categorize items such as "type" "subtype" "empty" "numeric"
currently, the functionality is more-than-adequate, but is always a work in progress. i have my TODO list in the Issues section. feel free to fork, make pull requests or report any bugs or enhancements.
for folding/unfolding, the example page links jQuery 1.6.1 and uses a small dump_r.js file to initialize the click handlers. it would be pretty easy to kill the jQuery dependency with some good ole' fashion plain DOM js, but i didn't feel like it since most of my projects already have it loaded
If I were going to use something outside of the core functions for dumping I generally use dBug because I find the cfdump-style a lot easier to read for larger objects. But, I'm sure this will be useful to people.
some refactoring and quite a few improvements made. including circular references, relative date indicators, callbacks, xml namespace stripping, removed jquery dependency for folding interaction, moved all code to a single file for easy inclusion.
attaching updated sample image, since i can't seem to edit the original post here.
__________________
"I only know that I know nothing."
-Socrates
you can already define how deeply you want to unfold initially. from the example, this will only unfold 1 level deep:
PHP Code:
dump_r($obj, 1);
you should be aware, though, that the library currently does NOT stop recursion at that depth, it always dumps everything and builds the full HTML. this parameter only sets the necessary CSS to hide deep stuff from you on initial render. i was considering adding an option that would in fact stop the recursion, and not render the rest of the object, leaving you unable to unfold it later. as for the performance, i'm not sure if what you're seeing is just the browser's sluggish HTML rendering of such a huge DOM structure (this would cause slow interactive folds/unfolds also), or the library itself taking a long time to digest the object. i dont see anything that can be done about slow DOM performance unfortunately, except falling back to rendering a <pre> with the contents of either var_dump() or print_r() past a predefined depth - but that aint pretty - i'd rather just not render anything. the object analysis itself i have not benchmarked but i tried not to leave too many low hanging fruit there while still maintaining the useful stuff.
can you give me an idea of size and format of the structure you're dumping and into which browser? maybe a specific analysis function is taking a disproportionately long time. i've personally dumped some pretty large stuff without experiencing noticeable slowness.
__________________
"I only know that I know nothing."
-Socrates
The code was getting soupy, so it went through a full OOP/PSR-0 rewrite. Additionally, it will dump uniform arrays of objects or assoc arrays as record tables. See attached screenshot or try it out at http://o-0.me/dump_r/
Unfortunately as a result the lib is no longer a single file, though it's still a single-file-include, whether installed through Composer or without. Also, the way in which it can be extended has improved significantly over the prior version.
__________________
"I only know that I know nothing."
-Socrates
Before you post, read our: 
my take on a better print_r() and var_dump()
