Efficient spike detecting Microprocessor or DSP architecture
If you just want to detect spikes, you don't need much processing power.  You can easily make a analog circuit that holds the spike high level for a little while to give a processor a chance to detect it at the next periodic A/D reading.  Or, the circuitry could detect the spike and drive a interrupt pin of the processor so that it can do whatever you want it to do immediately.

A brute force approach would be present the signal at the right amplitude and impedance to a A/D input of the processor, then do everything in firmware from there.  Some of the dsPIC 33F can sample at 1 MHz or more, but you didn't give any specifics to know whether that is good enough or not.  Such a processor would take a few 100 mW to run at full speed.  Note that you only get 40 instruction cycles per reading at 1 MHz sample rate.  That's enough to just detect a spike.  If subsequent readings aren't needed for a while as you process the spike (whatever that means), then this would work.

If the spikes are really short, you can preceed the A/D with a analog spike-stretcher.  Something like this:



A short positive spike comes in and causes C1 to be charged up.  Even if the spike goes away immediately after, the voltage on C1 will stay high and decay with a time constant of 10 &micro;s, which is a half-life of 7 &micro;s.  If you don't need to detect another spike for a few &micro;s after one, then this sort of spike-stretcher relaxes the sample requirements on the processor.

The actual decay time and impedances will likely need to be adjusted to your particulars.

Update:

It is now apparent you are trying to measure characteristics of low bandwidth signals.  "Low" being relative to what modern microcontrollers can easily measure and digest.  In this case you don't need any fancy external analog circuitry other than to present the right amplitude and impedance to the processor A/D input.  You can sample the signal at let's say 2 kHz rate with analog filters that start rolling off at maybe 300 Hz.  With that kind of setup, the sample stream is guaranteed not to miss any features.  And, at 500 &micro;s/sample, there should be plenty of time do peak detection and other processing.

This is really not that hard a problem, unlike what it appeared you were originally asking about.