4 ms·

Takes less than 100 ms to read in the file (calling realloc in a loop), insert a byte in the middle (realloc + memmove), and write the modified file out on stdo

by clarry 7y ago

Takes less than 100 ms to read in the file (calling realloc in a loop), insert a byte in the middle (realloc + memmove), and write the modified file out on stdout. The byte insertion amounts to about 4ms. That's hardly fast, yet still a lot snappier than most modern editors' UI or the web, where apparently achieving 60 fps for a few hundred dynamic DOM nodes is some kind of an achievement. https://gist.github.com/hmkemppainen/376b973c568fc122e2d8c843b49e8d0d https://gist.github.com/hmkemppainen/376b973c568fc122e2d8c84... This approach really starts to suck when you implement macros that are going to perform a lot of one-char inserts quickly. Or when you're editing multi-gigabyte files.

jstimpfle 7y ago
I must admit I was surprised, although I shouldn't be. Are we at > 10GB/s memory bandwidth now? > This approach really starts to suck when you implement macros that are going to perform a lot of one-char inserts quickly. Or when you're editing multi-gigabyte files. I'm working on an editor that I've optimized for such cases. In a test it made random edits to a 4GB file in < 50 microseconds. But, it cost a load of sweat and blood to get that rope data structure right. And it loads files only at about 100MB/s (should optimize for bulk inserts). https://github.com/jstimpfle/astedit https://github.com/jstimpfle/astedit
- userbinator 7y ago
  Are we at > 10GB/s memory bandwidth now? It's been around a decade since that line was crossed. The peak bandwidth of DDR3-1333 is just a bit over 10GB/s.
- cerberusss 7y ago
  Interesting project. You don't say so specifically, but it looks like it should compile on both Windows and Linux?
  - jstimpfle 7y ago
    Yes, I make it to compile on both platforms from time to time. The current commit should compile using MSVC, gcc, and clang I believe. I'm happy to fix any issues if you find them :-)
phkahler 7y ago
>> This approach really starts to suck when you implement macros that are going to perform a lot of one-char inserts quickly. What operation is that? Search and replace might have that effect but could be done by copying the entire buffer with replacement happening along the way.

by clarry 7y ago

jstimpfle 7y ago

I must admit I was surprised, although I shouldn't be. Are we at > 10GB/s memory bandwidth now? > This approach really starts to suck when you implement macros that are going to perform a lot of one-char inserts quickly. Or when you're editing multi-gigabyte files. I'm working on an editor that I've optimized for such cases. In a test it made random edits to a 4GB file in < 50 microseconds. But, it cost a load of sweat and blood to get that rope data structure right. And it loads files only at about 100MB/s (should optimize for bulk inserts). https://github.com/jstimpfle/astedit https://github.com/jstimpfle/astedit

userbinator 7y ago
Are we at > 10GB/s memory bandwidth now? It's been around a decade since that line was crossed. The peak bandwidth of DDR3-1333 is just a bit over 10GB/s.
cerberusss 7y ago
Interesting project. You don't say so specifically, but it looks like it should compile on both Windows and Linux?
- jstimpfle 7y ago
  Yes, I make it to compile on both platforms from time to time. The current commit should compile using MSVC, gcc, and clang I believe. I'm happy to fix any issues if you find them :-)

phkahler 7y ago

>> This approach really starts to suck when you implement macros that are going to perform a lot of one-char inserts quickly. What operation is that? Search and replace might have that effect but could be done by copying the entire buffer with replacement happening along the way.