Speed or Security

Parent Previous Next

Speed or Security.

When a SCRAMBLECODE VM executes bytecode, each virtual assembler instruction will use more clock cycles than an equivalent native assembler operation. Also if any operands are involved, they may require clock cycles to decrypt and (if a result is produced) to encrypt the result before it is pushed onto the stack or stored in memory.

Some of the virtual assembler instructions can perform their task without having to decrypt the involved variables. Being able to perform an instruction directly on an encrypted variable is both very secure and fast as exemplified here. Fortunately these instructions are used a lot in most programs.

However, a good deal of the virtual assembler instructions are more processing intensive and may require decryption and/or encryption of data values.

Finally some overhead also goes into clearing the content of disposed variables on the heap, writing zero-bytes into their storage locations when these are handed back as free blocks to the memory manager.

Speed Considerations.

The price of all these "extra" clock cycles is speed reduction.

Any functionality implemented in SCRAMBLECODE will execute significantly slower than compared to C/C++ or similar languages.

This means that for every secret function you want to port to SCRAMBLECODE, you must ask the question: "Will it execute fast enough?"

The answer is usually easy to get by just using the integrated test bench of the IDE - not having to involve your own application at this stage. As a rule of thumb SCRAMBLECODE is suitable for most scenarios - perhaps with the exception of really heavy processing algorithms. In case such heavy processing must be performed by SCRAMBLECODE, it might be accomplished by making use of parallelization and exploiting the possibilities for multi-threaded VM execution.

The extra clock cycles and the associated loss of speed cannot be ignored but must be accepted as security related clock cycles, which represent the extra security you get - and the problems the cracker is faced with - compared to executing an unprotected program.

TIP: Please notice that the bytecode may execute significantly slower, when it includes lots of trace instructions for debug analysis. Always switch this option off in the Project Properties to get the smallest amount of bytecode when evaluating the execution speed for a certain requirement.

Load Delay.

When a VM performs a safe-load of the bytecode doing public key authentication etc, there will be a small load time to consider, even if the DLL already exists in memory. Also keep in mind, that if the bytecode is loaded from a file, the speed of the hard drive must be considered.

In some situations a load delay may be a problem - e.g. for services with a recurring need for invoking VM execution of multiple VMs in separate threads. For scenarios such as these please consider using some sort of VM pool allowing you to reuse VMs with the bytecode preloaded.