java - Using Cipher.doFinal(byte[] b) decrypts faster after first decryption? -

i have following code:

keygenerator keygen = keygenerator.getinstance("aes"); keygen.init(128); secretkey msecretkey = keygen.generatekey();  public byte[] encrypt(byte[] data) {     try {         cipher c = cipher.getinstance("aes/cbc/pkcs5padding");         secretkeyspec k = new secretkeyspec(msecretkey.getencoded(), "aes");         c.init(cipher.encrypt_mode, k);         byte[] encrypteddata = c.dofinal(data);         return bytes.concat(c.getiv(), encrypteddata);     } catch (exception e) {         e.printstacktrace();     }     return null; }  public byte[] decrypt(byte[] encrypteddata) {     try {         byte[] iv = arrays.copyofrange(encrypteddata, 0, 16);         secretkeyspec k = new secretkeyspec(msecretkey.getencoded(), "aes");         cipher c = cipher.getinstance("aes/cbc/pkcs5padding");         c.init(cipher.decrypt_mode, k, new ivparameterspec(iv));         byte[] decrypted = c.dofinal(arrays.copyofrange(encrypteddata, 16, encrypteddata.length));         return decrypted;     } catch (exception e) {         e.printstacktrace();     }     return null; } 

for reason, find if execute following:

byte[] encrypted = encrypt(some_byte_array);  byte[] decrypt1 = decrypt(encrypted); byte[] decrypt2 = decrypt(encrypted); ... byte[] decryptn = decrypt(encrypted); 

that first ever decryption (and on occasion first couple) take longer following decryption. not limited decrypting same encryption, however. example, if encrypt 2 byte arrays, a , b, if decrypt encryption of a first, decryption of b execute faster.

so basically, first (sometimes couple of) call(s) decrypt slower subsequent calls. did of own benchmarking , found difference seems in call c.dofinal(arrays.copyofrange(encrypteddata, 16, encrypteddata.length), takes longer first (sometimes couple of) times around after.

i apologize in advance if dumb question, , help.

the first time byte-code run in java typically compiled (by jvm) native code through jit compiler. after that, saves native code , uses again. therefore, expect subsequent invocations faster first. see also, startup delay , optimizations.