The plugin has now been in development for over a year and a half.
Although it is approaching functional completing, it has become somewhat slow.

Potential code optimisations will be tracked in the comments of this issue.
They will be addressed as milestone 1.1.0.0

From what I've experienced, changing the permission to use strings removed a lot of sluggishness in the plugin. Still, for large servers, there are probably more optimizations avilable. Looking at timings, it seems the synchronous populator and the block break listener are the slowest parts of the plugin.

Got any ideas on how to increase the performance of the synchronous populator?

Maybe like a return statement if the queue to cycle through is empty?

When does this performance readings come from btw, is it during startup?

The most obvious optimization, if possible, would be to make it asynchronous. Most lag from the Synchronous populator is probably the same kind of lag caused by WorldEdit.
I don't see any wasted effort when the block queue is run through, but we probably need to do a big-O analysis to be certain if things can be improved.

I think the performance timings are a thing added by Paper. I didn't find it until switching to paper. You use /timings on, then do a bunch of stuff for at least 5 minutes before using /timings paste to get a performance report.

Got any ideas on how to increase the performance of the synchronous populator?

Maybe like a return statement if the queue to cycle through is empty?

When does this performance readings come from btw, is it during startup?