Problem:1713D - Tournament Countdown
My submission in java:189203654 (TLE on test3)
My submission in c++:189201160 _(779ms)(Most part of them are same, expect time cost of IO)
If there are no testers of rounds using java, maybe I should give up.
№ | Пользователь | Рейтинг |
---|---|---|
1 | tourist | 4009 |
2 | jiangly | 3823 |
3 | Benq | 3738 |
4 | Radewoosh | 3633 |
5 | jqdai0815 | 3620 |
6 | orzdevinwang | 3529 |
7 | ecnerwala | 3446 |
8 | Um_nik | 3396 |
9 | ksun48 | 3390 |
10 | gamegame | 3386 |
Страны | Города | Организации | Всё → |
№ | Пользователь | Вклад |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
2 | maomao90 | 163 |
4 | atcoder_official | 161 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 157 |
8 | TheScrasse | 154 |
9 | nor | 153 |
9 | Dominater069 | 153 |
Problem:1713D - Tournament Countdown
My submission in java:189203654 (TLE on test3)
My submission in c++:189201160 _(779ms)(Most part of them are same, expect time cost of IO)
If there are no testers of rounds using java, maybe I should give up.
Название |
---|
Fun fact: I submitted the c++ solution without IDE, which caused "Compliation error" 3 times.
I am just going to assume you are new to this and not an alt created for trolls.
there are no testers of rounds using java
CP in general is a sport, and one of its pillars is speed. Which means you need to think fast, code fast, and programs need to execute fast as well. So it's a no brainer that most people go with C++ as their go to language. You can see this comment as well.
This however means, its difficult to find quality testers of slower languages. This is one of the contests I remember where the setters had made sure Java passes for each problem.
maybe I should give up
If you enjoy programming in a language, and you are most comfortable in it, I see no reason to completely throw it away. There are users who became LGM using python, not to mention several reds who regard java as their primary language. All that being said, sometimes we will run into trouble, and we do need C++ to save us from bricking.
It does get somewhat challenging with Java at times, but more often than not, I find that it is either my logic that is suboptimal or there are some language details that I don't fully understand. On occasion, it has happened that an $$$n^{1.5}$$$ solution passes in C++, and TLEs in Java, well the optimal solution in this case was $$$n*log(n)$$$. There are also times when I find people using language features that were novel to me.
Even for this question as well, I see that while your solution TLEs on Java, there are numerous others that get an AC verdict well within the time limit. You can check that here. If you're interested, you can have a look at some of these codes and see what they're doing differently.
As a fellow Java coder I understand that this isn't a fun experience, but oftentimes, I get to learn something new about the language or solving in general.
Lastly, while substituting your default I/O with faster alternatives didn't give promising results as such (barely passed after repeated submissions, ac submission, try to use Java 11, though sometimes on CF, Java 8 gives slightly faster results), I'd still suggest that you shift to a faster I/O. Here's the link to the fast I/O that I use, which per my tests is faster than the BufferedReader/System.out pair. There are faster alternatives still, but this one fits my current understanding. You can also have a look at uwi's code, he codes in Java as well.
PS: Do reach out to me if you'd like to have any more discussions on the language. I'd love to interact with a fellow enthusiast. Happy Coding :)
However, the most optimized java submission still need 1000+ms (and many of them need 1900+ms), which means the problem would be completely unJAVAble if TL is 1000ms, while any c++ submission with basic optimization runs for less than 1000ms. Therefore it makes nonsense to use java in problems with massive interaction.