Блог пользователя WORTH

Автор WORTH, история, 9 месяцев назад, По-английски

Hello everyone.

Context
TLDR
  • Проголосовать: нравится
  • 0
  • Проголосовать: не нравится

»
9 месяцев назад, скрыть # |
 
Проголосовать: нравится 0 Проголосовать: не нравится

I maybe wrong but are u sure that the static buffer array was slower in runtime, not due to compile-time.I didn't saw the code but afaik you might be declaring a large static buffer array which may increase the compile-time significantly

»
9 месяцев назад, скрыть # |
 
Проголосовать: нравится +3 Проголосовать: не нравится

I cannot yet understand why first is faster, but note that you use BufReader in both cases, so no need to bufferization on top of it

  • »
    »
    9 месяцев назад, скрыть # ^ |
    Rev. 3  
    Проголосовать: нравится 0 Проголосовать: не нравится

    Makes sense. I tried using the internal buffer instead of creating a new one (submission).

    It is faster than the previous code, but still slower than the first idea.

    My guess is the number of Strings (one for each input).

    Edit: The default capacity of the strings was 16, which is not enough for 64-bit integers. I increased it to 20 and got close to 200ms (Submission)

    Maybe I can use a single string for primitive types (instead of creating them for each input) and that'll reduce the time.

    Edit 2: I guess this will work fine for now. Maybe in future I'll dig deeper into making the IO faster than this. Thank you for your insight.

»
9 месяцев назад, скрыть # |
 
Проголосовать: нравится +3 Проголосовать: не нравится

Could be due to increased CPU cache utilization for input buffers, which leaves less room for other data needed during runtime. Anyway, best way to figure out why is to profile it.

»
9 месяцев назад, скрыть # |
 
Проголосовать: нравится 0 Проголосовать: не нравится

Is there in Rust something that reads the entire file (using WinAPI or unix system calls), like this in C++?

Spoiler