>generate a 14gb 300mil lines file
>try to open in emacs
>it fails because it tries to load the whole file to memory
>try to open in nano
>fails for the same reason
>try to open in vim
>it takes a minute or two to load and takes almost 7gb of ram
>try to open in kwrite
>it tries to load the whole thing to memory and crashes the system
>try to open in gedit
>takes ages to load that I give up and close it
>try to open it in vscode
>takes around the same time to open as vim. takes less than a few mbs of ram
I kneel vscode chads
you won this time
 |
 DMT Has Friends For Me Shirt $21.68 |
|
Buy an ad Saaaar
>14gb 300mil lines files
what's the use case for this
none of your business, fed
Use a database, homosexual.
What do you think a database is? Yes homosexual, eventually its just a big ass file
...that is used by a program which is optimized for reading big ass files and writing into it without having to load much into RAM. It also has an API for most features you would need.
NOOO BUT MY B-TREE INDEXES AND HASH JOINS I AM VERI SMARTTT
>be moron
>do moronic shit
>complain moronic shit does not work
>yea so i ugabuga loaded an entire databse into ram and now i am getting mad that it ddi not work, this is the fualt of linux and FOSS software, not my own stupidity, no frick you you are a pajeet.
>be moron
>do moronic shit
>its okay because vscode got your back
Pretty chad ngl
I hate VSCode because it has no soul and it's a typical microshit monopoly that is eating up the market and slowly killing mass interest in other alternatives. Also because it's objectively the best editor out there at the moment. Using anything else right now feels like purposefully tying one hand behind your back. I hate it but it's true.
>Using anything else right now feels like purposefully tying one hand behind your back.
Everyone says this but every time I use it, it feels just... okay. There's nothing special about it at all if you are used to editors with actual features.
I feel like the people praising VSC as the second coming of Christ are used to editors that are essentially Notepad with syntax highlighting.
>big ass file
Every DBMS recommends multiple file groups for this scenario.
He's gorgeous
Tons of software log to a file, like apache web servers. And they get big fast.
if only you could divide the logs into smaller files
Course you can, but a lot of software doesn't by default. And what most people (including me) do is log each day separately. But if I then get abnormal traffic, it might get bigger than expected.
You're gonna encounter that multi-gb text file before you want to change it.
or append to logs...
he has a point though, you'll find the big dump one day, but you can still just divide it with bash and easily digest
I don't have time to replicate it so you may be lying out of your ass but I believe it. VSCode is pretty awesome. The morons who go "hurr durr durr VSCode is sooo bloated because it's made in JavaScript lmao" don't get that languages are not the thing that is slowing your program down, it's the algorithms and the data structures, if you use a higher level "slow" language like Python or JavaScript to implement a better algorithm or data structure for your program then of course your program will be faster than the naive C implementation.
Opening giant files is pretty much the one reason I ever launch VSC, and even then it's pretty rare that I even need to do so.
anon is right, VS code has no problem opening massive files and i also use it for that reason
Neither does excel. All other freetard spread shieeets just crash. Excel? No big deal
i assume freetard software tries to load the whole thing into memory, which is fine for 99% of cases, but MS software treats the open file more like a virtualized view through which it seeks
Excel is meticulously engineered to handle all of the pants-on-head moronic shit that boomers do with it on a regular basis.
>languages are not the thing that is slowing your program down, it's the algorithms and the data structures
I can't believe IQfytards don't understand this concept when there are tons of shit devs that don't even know how to properly optimize their programs for better memory management and think it's solely the language's fault
Saying it's not the language's fault is just as simpleminded as always blaming the language. You are the hurr durring caveman you wish to portray other people as.
>hurr durr durr a good python implementation is of course faster than a naive interpretation on an appropriate language.
That does not change the fact that some languages are still faster, moron. It also isn't even necessarily true. A "better algorithim or data structure" does not always compensate for the innate disadvantages of the language. It would defend on how much better it is. I know that saying things like "of course your program will be faster" allows you to feel like you know something. But you don't. You actually have to think about specific situations instead of reaching out for simpleminded conclusions.
>What is HxD?
ngmi
>windows
negmi
clear your damn logs
Try sublime
The fact you even added Gedit there is hilarious.
That piece of shit struggles opening base64 strings of any reasonable length kek
It's honestly worse than the old Microsoft Notepad. You know the one, the one people avoided and used Wordpad instead because Notepad SUCKS. Thank you write.exe
Notepad is more performant than any linux replacement so far.
It is legitimately faster to open large files in a windows xp VM than in a native linux notepad like application 😐
Shard it into 1,000,000 14kB 30-line files.
is OP an empiric Chad, or is he a MacroShit shill?
Hate VSCode just because I hate the interface, but this is good to know because this problem comes up now and then. Good reason to keep the pos around.
Your vim is slow because of the highlighter, type ctrl c right after opening and it will be instant.
so share the file then we will see
#include <stdio.h>
int main()
{
FILE *fd = fopen("output.txt", "w");
for (int i = 0; i < 300000000; i++)
{
fprintf(fd, "/g/tards are huge homosexuals, they enjoys sucking on BBCn");
}
fclose(fd);
}
log level = moronic stupid.
just use VLF in emacs?
>11 years ago
once again, programmers of the old had everything figured out
>Open in IntelliJ
Takes 0.5s
Yes and no, as you can see with this example where i load a 120MB log file on both neovim and vscode.
It is an approach that has benefits(ram usage but also usability drawbacks
> Much like Kwrite vscode will not load the entire file
> VScode will also turn off extensions like my extension to prevent freezing or crashing.
Meanwhile neovim just loads the file instantly with any and all assumed extentions enabled and i can also search the entire file.
There is a benefit to using the ram I have available on my PC.
There's a saying, unused ram is wasted ram.
But i think ram is even more wasted when you need to load a web browser that pretends to be an editor.
Pretty sure Kate and by extension kwrite warn you when opening huge files.
yes graphical applications don't load the entire thing. Because that would be insane.
Not so fast
I *think* (happy to be proven wrong) that micro has the same filesize limitations that nano/jed etc. will have.
It will try to buffer 14gb which unless you have the spare mem and swap will just break.
this
also micro's text buffer is a literal array of lines
>do you want an extension for this file type anon?
>sure why not
>8GB consumed
>CPU hovers around 20% continually
>still works flawlessly
Power of JavaScript