1. Is nebula optimized? The question is masking an other one: 2. Is the developer crappy?
The real question is: 3. is nebula optimized like other plugins, or simply other developers could do similar things in a better way?
So let's answer. Question 1. Is nebula optimized? Yes. Nebula is optimized because we spent A LOT of time in that. We've been developing this baby for 5 years, which is an amazing amount of time. Maybe you will not find easily something similar in the vst market, because not all fx products survive for such a long time. So we had the chance to optimized the code a lot.
To be fair, the real answer is anyway different: in the software world NOTHING is really optimized. If something could be tuned further, you need just a bit of time and you'll do that. Something really complex could be tuned again and again and again, because there are so many things you could fix. What's important is the tradeoff between time spent on improving the code and results.
Here few tips about the optimization achieved by nebula, maybe this paragraph could be interesting for a developer point of view. Just to prove we aren't stupid 1. direct convolution is performed using ASM language. Few algorithms optimized for ia32 and emt64, best one is chosen at run-time 2. on windows side, crappy borland compiler was substituted with microsoft compiler. Latest release obviously. 3. we adopted the fastest library available for FFT, intel IPP library. We were early adopters of FFTW. 4. we were early adopter of CUDA. Don't think for a while we are using standard FFT libraries there, we tuned vasily volkov algorithms, creating a personal customization. Yes, we tuned a lot of cuda code and we profiled FFT for each incoming block size 5. The original implementation of AnsiString (strings) was substituted with a different implementation based con CString, and we substituted it again with a string implementation largely developed in ASM. Our custom implementation obviously is faster than microsoft one. Why we need such a fast ansistring? because nebula works with tons of xml files and this lead to the next point 6. We tuned a very fast implementation of XML. Like in a lot of games, if you need a fast game you need a fast XML parser. I dedicated a lot of time on that. XML is the hearth of this plug-in, (think to program loaders, they are parsing hundreds of megabytes of data in few seconds) so it should be fast!!!! 7. Yes, we have a memory manager. And a pretty amazing good one. We didn't add the code you will find in a lot of games (new, delete overrides) becase... we wrote our custom version, which is more suitable for our scopes. Every malloc and free is aligned, and more important, logged and profiled. 8. On mac osx side we wrote our custom implementation for threads, we rely on pthreads (and not mac osx garbage), for events and queues. Guess the reason: speedness!!! 9. as you can see, presets are cached, so loading time is faster. Like in many romplers 10. vector engine is based on a fast tree implementation. The idea was grabbed from 3d games (the main idea was grabbed from bsp partitioning used in early doom/quake games). CoreII is heavily based on caching of data. Hard work, hard work, and again hard work. 11. mono processing is obviously optimized, and so vectors are cached when variables don't change and so on. We avoid to perform unnecessary IFFT if possible.
.... many other points which I don't remember. Too many.
second question 2. Is the developer crappy? Well... not really. I would say medium skilled, but with a lot of time to spend on the project. What a lot of you don't know, the audio market is a niche. Even when you think a product was created by a large team, it's not true in most of cases. You can't cover costs otherwise, so you can't manage the same things using a larger team. About skills: a game developer could be more skilled than me for sure. But I don't think Carmack would spend his time for those little earns.
The most important question 3. is nebula optimized like other plugins, or simply other developers could do similar things in a better way? yes, it's optimized, even better than other plugins, but the approach is brute force. We don't optimize a particualar situation, our engine (think as it was a 3d rendering engine) is general purposes. Which using new processors is the best choice, because it's flexible. Computers are faster and faster, so developing time is the real bottleneck. A general purposes and well organized engine is a good compromise.
BUT we tuned things in order to achieve the maximum quality possible. We don't need an other plugin. We are fighting for the best quality plug-in, and this is possible ONLY if we don't limit it in any way. We are trying to give to you the sound of the future. If you are not interested in that, other plug-ins are maybe more suitable for your workflow and time. My suggestion: buy a fast computer. The experience you'll have using i7 featuring W7, SSD disks and tons of ram is completely different from the one you'll have using a dualcore. We are trying to emulate expensive hardware and vintage outboard, you just need a fast (but still cheap) computer.