The results from the VisualVM are quite puzzling, because they don't mention other methods invoked beside the two marked as hot spots;
and also because the first one is a two-line-long final method that I expected to be expanded inline by the JVM.
But, indeed, they spot an operation that is likely to be involved in this CPU problem; and it is not easy to fix it.
Actually, your usage of the COMMAND mode, by sending thousands of real-time ADD events in a loop, is a use case that was not expected and was not optimized properly.

You could resort to the snapshot case and send the events that make up a search result as part of a snapshot.
This means that you cannot have a persistent subscription on which to send the search results, but that you have to perform a one-shot subscription for each search, so that you can leverage the snapshot for the answer.
The snapshot in COMMAND mode is handled in a different way that does not involve the reported bottleneck.