Kint fixes, performance, plugins, and feedback

Hi! Kint maintainer here.

While I'm well aware devel uses kint I've never dug into the devel code. The first thing I saw were some hacky workarounds with comments suggesting it's a bug in Kint.

If you suspect bugs in kint please actually send them to the kint repo. Even if it's a wontfix I'll suggest some workarounds. I get almost no feedback from devel besides invalid bug reports from users with an outdated kint version.

Custom naming

Kint can be used as a library rather than only through the dump facade, and in that case you can set the variable names to whatever you want.

So I changed the existing code that does some string replace hacks to just use it as intended.

Without composer

You cant use Kint without using Composer

Actually you can. I provide a reproducible PHAR build checksummed and tested in CI, so maybe you'd want to add that to the docs since some users were asking for it.

Performance

I got nerdsniped by the poor performance and wrote a kint plugin to profile it...

Turns out it's really hard to narrow down what's causing performance issues when drupals caching system pseudorandomly fixes or worsens it, but I have a rough idea of what the main culprits are.

Services

I looped through dumping every service in the container and measured how long it took, how much ram was used at peak, and how much output it generated (Which is the biggest "Perceived" slowdown since kint produces output faster than the browser can render the DOM)

When blacklisting specific classes/interfaces these are the results:

Baseline (Container & EventDispatcher):  111.248s | 797MB ram | 2972MB output
ConfigFactory:                           91.321s | 756MB ram | 2433MB output
Connection:                              81.580s | 707MB ram | 2125MB output
ModuleHandlerInterface:                  72.795s | 673MB ram | 2185MB output
PluginManagerInterface:                  46.565s | 493MB ram | 1335MB output
MHI & Connection:                        59.268s | 602MB ram | 1570MB output
MHI, Connection, ConfigFactory:          46.053s | 571MB ram | 1241MB output
MHI, C, CF, PluginManagerInterface:      20.058s | 250MB ram | 523MB output

ModuleHandler is the single biggest culprit, followed by Connection and ConfigFactory. Shallow blacklisting these 3 alone will reduce dump time by 60% on average.

PluginManagerInterface is implemented by a bunch of services. I don't know how important it is to see what's in here but it knocks another whopping 60% off bringing us down to 18% of the original runtime.

ClassStaticsPlugin/ClassMethodsPlugin/IteratorPlugin from kint have almost no effect on performance. Methods/statics are mostly cached by class and the only iterator of note was the service locator which is already blocked by the Container blacklist.

When dumping individual services the average service goes from 136ms to 29ms with these changes for a nearly 80% speedup.

Nodes

Ah. Now I see why you blacklisted IteratorPlugin. Did you know IteratorPlugin has its own blacklist? That fixes most of the performance without losing you the ability to inspect iterator contents but it's still rather non-obvious how to access fields on nodes. (That's drupals fault, not devels)

Anyway, I wrote 2 small plugins to improve the output and now it dumps generated nodes in about 34ms each, or 57ms each when dumped a second time (Because extra info has been put into fields and fieldDefinitions)

You can eke out more performance with more work but this is "good enough for now" since I only took a quick look at it.

Feedback

Since I'm not a daily drupal driver myself, I'd like some people to try this out and give feedback. There's probably some frequently used system I don't know about that has bad performance or something.

I'll submit a PR in the morning. The changes are on my fork here: https://gitlab.com/jnvsor/devel/-/commits/kint

And again, if something looks like a bug in kint and you're on the latest version please report it, I can use the feedback!