We have seen kiwi syslog pre-filtering improve the performance in Orion environments not only from processing the log load on the pollers, but also overall DB performance. If you are properly pre-filtering messages to only actionable items, you are reducing reads and writes to the DB and in cases where syslog is noisy in an environment this can be a decent amount of data that doesn't need to reside in the Orion DB tables. If you still want that noisy data, kiwi can offload it into flat files or a DB that is not a part of your monitoring solution and is more of a data warehouse for syslog for auditing/reporting purposes.
The 2 general approaches that I have suggested in the past on getting to where you want to be with syslog monitoring using kiwi syslog server as the primary processor:
Filter known noise and forward everything just adding to the noise filtering until you reduce what is forwarded to only actionable items.
Filter know issues and forward them on, filter noise and drop it at kiwi, store all unknown content as a flat file or in a DB for review until you decide it is noise or actionable.
We have seen pushing the load off to a syslog help in several cases in client environments, so I would suggest it especially if you are considering a decent load of new nodes and are already seeing performance issues.