The Netgate team did some throughput testing some time back shortly after the Inline IPS Mode option was added to the Snort package. I no longer have the emails we swapped, but if I recall correctly there was about a 100 MBits/sec penalty with Snort running with a moderate rule set. This was likely on one of their higher-end appliances (but bare metal, so not apples-to-apples when comparing to virtualized).
One thing that also matters is the type of traffic in the throughput test. Small packets versus large packets, for example. I'm talking about the payload size when I say "small" and "large". Every packet has a certain amount of CPU overhead in order to get processed. That overhead stays pretty constant no matter if the packet is a 64-byte icmp-request, or if it is a full-frame 1500-byte TCP packet. The overhead I'm talking about is wrapped up in pulling the packet off the wire and copying it into kernel memory for processing.
But when looking at throughput, most all speed tests are just measuring total bits or bytes received over some unit of time (typically per second). As an example, about 42 1500-byte packets will deliver the same amount of "data" per second as 1000 64-byte icmp-reply packets. Obviously the CPU is going to be doing a lot more work over the same time interval to process 1000 packets as compared to only 42. The true measure of throughput is pps (packets per second). This removes the "packet size" variable from the equation. So one thing some throughput tests do is mix up the composition of packets in the test data stream. They generate a mix of small, medium, and maximum payload packets in an attempt to more closely mimic real world traffic.
So my point with the long description above is that you should not assign too much importance to the results of a speed test. Instead, examine the real day-to-day performance of your network. Do things seem to still work at the same speed? Do web sites still load at the same rate? Are users complaining about speed slowdowns? An IDS/IPS will slow down your packet processing by some amount. That's just unavoidable, because you have added a large amount of extra work for the CPU to do. It has to pull the packets into the IDS/IPS, analyze them by comparing each packet to all of the signatures, and then make a go/no go decision for the packet. The CPU cycles expended doing that have to come from somewhere.
