Всичко хубаво, но поне ако може да вдигнете малко времената, защото решението на лектора от миналото издание 1:1 не минава по време на 3-4 теста (а на видеото, решението му минава със 100/100)

Не са добре времената нещо, да... Същото решение с няколкото часовника като го преписах от C# на Java и мина без никакви проблеми. 

Това е една от малкото задачи, при които решението на Java е по-бързо от C# такова. *

Едно възможно обяснение, е може би по-бърза работа на Java с BigInteger, защото това е единственото по-специфично нещо в решението на тази задача.

* Когато съм правил сравнения, най-често решенията са сходни като време, а в останалите случаи C# е по-бърз.

Наскоро загубих няколко часа в оптимизации на алгоритъма и микрооптимизации на кода на една задача, докато открия, че забавянето (0.16с при 0.1 разрешени) идва от използването на стрийм за парсването от конзолата на 2 числа до int[]. Премахването на стрийма смъкна времето с 50% (под 0.08с) и задачата мина. Знаех, че стриймовете са бавни, но за първи път се сблъсквам с толкова ясно изразен проблем. :)

Мартине, това което казваш е много интересно. Можеш ли да шернеш конкретни примерни за парсването?

Възможно е и Java да се справя по-добре с работата с големи масиви. Примерно на Rectangle Intersection бавното решение с матрицата 2000х2000 въобще не минава на C# и като памет, и като време. С Java същото мина 100/100 и то с разлика под границите. Не съм пробвал на други задачи, така че нямам по-сериозни наблюдения. 

@viraco4a

Разбира се!

Това е задачата на Java - разликата в кода е само в парсването на първия ред от входните данни.

Вариантите на решението може да се тестват тук.

@k.sevov

На теория поне, не би трябвало който и да е съвременен език да е бавен при работа с големи масиви, защото това е доста базова операция и аз лично съм по-склонен да мисля, че в конкретния случай при Java сработва някоя оптимизация, която липсва или не е толкова добра в C#.