In debug mode, taking too much time to calculate exponential comparable to Android native BigInteger.

[gmtek]

Below exponential calculation (2048 bits) is taking around 5s whereas same calculation using Android native BigInteger is taking around 100ms.

        let N = BigUInt("AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B855F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773BCA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB694B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73", radix: 16)!
        let g = BigUInt(2)
        let a = BigUInt("601e4cdbc9ceadbd116fff9331c689b03d9770f5d4da80f8e0fe826f01104e9bb52d68a7bc38519d77d0463f4bc67cf9d13588e03324c7c79a6931dfc3d5b4b3b4014ec08820be1af9f9a056350ccaada53f063568671bd717217be2f90e948d037e00ea348f1bb4f99ca16ca4f11a889529afe80229127b10e85001c6654fbdb805f1122dc1b10679334228ab86ab65a3192f0368ca21f45e966e65adab6bf752844828b25923ad98da909c1b2ffae21625ce6095f0d15601475edd44a7a6979a48339f0265fabe7cb864a56e583c35f838eaa00e676658df7e091a5a3cf346f4df3ce65ed5633b7bb3ea7c2dec982a4ec9c7c6ad9eb3da33cf635ed6094c24", radix: 16)!
        let start = Date()
        let A = g.power(a, modulus: N)
        print("Elapsed time: \(Date().timeIntervalSince(start))")

[gmtek]

In release mode it's taking around 130ms that's awesome. But why this huge difference in debug mode? Note that Android was also in debug mode.

[koraykoska]

This is not something we influence in any way. Java code isn’t really "optimized" when production compiling as producing bytecode is already pretty efficient and optimizing compile times for debug mode is not really necessary. Swift code on the other hand behaves pretty similar to other native languages. Because compilation time takes very (very) long compared to Java or other virtual machine alternatives, the compiler developers try to optimize debug compilation time as much as possible in order to make our lives a little bit easier during development. Because of that some stuff performes pretty bad in debug mode whereas it’s awesome in production mode. You should never use the debug performance as an indicator for anything. AFAIK string manipulation stuff is pretty bad in debug mode. But there are certainly also other stuff performing rather bad. To solve this issue if you depend on this library for testing you could just set production mode for BigInt only, even in development. As the build will be cached nevertheless locally, you will not even notice it in your iterations.

…

On Thu 17. Oct 2019 at 16:39, Gulshan Mandal ***@***.***> wrote: In release mode it's taking around 130ms that's awesome. But why this huge difference in debug mode? Note that Android was also in debug mode. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#68?email_source=notifications&email_token=ACWUTTJVHLZB3PJYLWJGBV3QPB2K7A5CNFSM4JB2I6J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQKYTQ#issuecomment-543206478>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWUTTL4CAFXNOS5LEBL53TQPB2K7ANCNFSM4JB2I6JQ> .

[gmtek]

I agree that debug performance really doesn't matter. Just wondering what operation exactly makes this huge difference in performance between debug and release? I don't see many string manipulation operation either.

[koraykoska]

I don’t know it specifically for BigInt. Just profile it in debug mode and look which operation takes this huge amount of time. Should be quite easy in this case.

…

On Mon 21. Oct 2019 at 11:10, Gulshan Mandal ***@***.***> wrote: I agree that debug performance really doesn't matter. Just wondering what operation exactly makes this huge difference in performance between debug and release? I don't see many string manipulation operation either? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#68?email_source=notifications&email_token=ACWUTTOCNIJBKS22LO32L2TQPVWYDA5CNFSM4JB2I6J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBZT35A#issuecomment-544423412>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWUTTOARDYCSHAROZIJAXLQPVWYDANCNFSM4JB2I6JQ> .

[tgymnich]

Closing some old/resolved issues.