comodo programmers might already know this, but maybe they don’t who knows?
Here goes.
the seperation of sections is intentional so that different aspects of the application do not interfere with desired results(faster code for that particular function)
Also the order in which this is presented is also the order in which to optimise(as some features cannot be stripped entirely and get bottlenecked by other features)
Maximising scan speed:
*HDD access(Speeding up scan speed to the limits of the hardware)
-The “read data from disk” algorythm can be externalised to a simple application that tried to read the files/folders you point it at as fast as possible. Using this the “read data from disk” algorythm can be tweaked to the point that read tranfser speeds reach those of teracopy and hdtach.
(This same system can be used for writing(logging, installing and so forth))
*Hueristics, rules and signatures storage(speeding up the access to the database)
-The database these are stored in can be benchmarked too, again create a standalone application that only tries to read from the database. The database should be fully loaded into ram before benchmarking. Targets are how fast to scan the database from beginning to end, how fast to scan the database for random entries and scaling the database to huge sizes(Gb’s) and perfoming the same 2 benchmarks.
*File analysis(speeding up the scan speeds for analysing files to the limit of the hardware)
-Using the same method above a little program can be created based on the “file analysis” algorythm. The thing here is to create a benchmark. Feed the benchmark a bunch of files by pre-loading them in memory(to avoid the harddisk bottleneck) then tweak the algorythm to decrease the scan time.
NOTE: this last benchmark depends heaviliy on the database performance
This one is like the file analysis but more aimed at the firewall
*Network analysis(speeding up the scan speeds for analysing network traffic to the limit of the hardware)
-This benchmark is a little harder to do then the others.
First a small application needs to be made that is ready to recieve(and immidiately drop) any kind of packet over any port using any protocol, a second application, exactly the same but sending instead of recieving. These applications should be tweaked to the point where they are as fast as possible taking as little cpu time as possible while generating 100% usage on a gigabit or faster network.
Once this is achieved a benchmarking application using the Firewall’s “router/inspection” can be created, this application would have an allow all setting to prevent database slowdowns. All it does is recieve the packet its unknown so it has to analyse it, but the only rule to analyse with turns out to be allow so the firewall allows it.
Using this benchmark the network slowdown and cpu overhead can be tweaked lower. Using gigabit or faster lan makes sure you push the application to its limits. (The only problem with this is that gigabit connections use a large portion of cpu and pci-e bus, thus making it harder to benchmark the firwall test application)
These benchmarking tools should ensure that any application made by Comodo is as fast as possible on a basic function level (HDD read/write access, Database storage/retrieval, File/network/memory analysis)
Maximising Gui Speed/Responsiveness.
*Draw speed
-A little program to test the gui would simply draw some blocks to the screen and then show fps, tweak to get it faster.
General speedup advice:
Program for the future, adjust for the now.
for thehe applications(not the benchmarks, those should be written platform independantly) keep the following in mind when programming:
*My target user will have unlimited cores and threads(threaded programming easily scales back to single core)
*My target user will have a 64 bit processor(64bit should be trunk, 32bit should sync next to it)
*My target user will have the latest CPU with all its features(the benchmarks should be run on this cpu)
*The trunk code will be 64bit, with latests SSE version.
In reality users will have a mix of processors and SSE versions:
So the installer/runtime will check the users CPU features and silently enable the correct core.
Each core can even be compiled for a specific target CPU to gain more speed.
The DEV tree will look like this:
Trunk=64bit+latestSSE
64bit+olderSEE
SEE4
SSE3
(As far back as 64bit processors go)
32bit+latestSSE
SSE4
SSE3
(As far back as NO-MMX/SSE)
then for compiling you several profiles for the different CPU’s and you can auto-compile all kinds of different versions. Then the installer detects the cpu and bits and installs the right version.
This basically gives you all the optimisation you would get from compiling yourself. while still remaining a closed source application
It looks like a lot of work but usually you don’t update the SSE code often(especially since you already benchmarked the hell out of the non-sse code)
There was a lot more but i forgot for now, I willl post that next time if i remember