[Suggestion] Faster statement loading at the start of the contest

Правка en1, от Alon-Tanay, 2023-01-04 15:04:45

Hello codeforces,

The past two rounds (Goodbye 2022, Hello 2023) had quite a lot of participants, which is great, but comes with the downside of a very long loading time for the website at the beginning of the contest, reaching 5 minutes in "Hello 2023" for me personally.

This kind of delay is annoying in general, but especially during the critical first few minutes of the contest where wasting time on problem A is costly.

Now, the obvious solution would be adding additional resources to the server during peak times, but there's only one* big burst of requests and submissions and it cools down pretty fast, so in any case a method to move some of the load on the server to a different time would be very helpful.

My suggestion is publishing the problemset in advance, even 30 minutes before the start, encrypted. Then, at the start of the contest the encryption key would be broadcasted to everyone, letting them decrypt the relatively heavy statements on their own, and eliminating the cost of serving the full statements to every participant at the beginning of the round.

In terms of implementing this scheme, the contest page should be as light-weight as possible, it's only functionality being receiving the encrypted statements (or already coming with them) and waiting for the key, and it should be available in advance. There can even be an option to download the encrypted problemset. Also, in general there should be a higher priority for serving everyone the problems than for accepting solutions / showing the scoreboard (which would be empty anyway).

I'm interested to know your thoughts on this suggestion and on the problem it describes in general, or if you can think of any alternatives/improvements. Is it realistic? Would it make a difference? You decide! anyways have a good rest of the day, happy coding!

* Coming to think of it, I had the same problem at the end of the last contest, and almost couldn't submit my solution in time. This second growth in activity can probably be attributed to everyone rushing to submit what they have or refreshing the scoreboard, so in that case the opitimization I described above wouldn't work of course, but I also think the main priority is receiving the last submissions from participants and if we're dealing with limited resources we can wait with evaluation / calculating the scoreboard / other less time-sensitive functionalities. what do you think? (we can even do the reverse of serving encrypted problems in advance, and accept hashes of submissions instead in the last couple of minutes, then allow users to pair their hashes with their actual code for some time after the round is over)

История

 
 
 
 
Правки
 
 
  Rev. Язык Кто Когда Δ Комментарий
en1 Английский Alon-Tanay 2023-01-04 15:04:45 2832 Initial revision (published)