I have a Seagate Firecuda 520 2TB SSD with a TBW (TeraBytes Written) rating of 3,600. Let's say I want to ensure that I get a 5 year lifespan out of this drive. This would mean that I could write 1.97 TB of data to that drive EVERY SINGLE DAY for 5 years. I don't know about you, but I don't often write that much data to a drive in a day.
Let's assume I had a 1TB SSD. That would cut the TBW rating in half which would allow for 0.98 TB written every single day for 5 years. That's still a tremendous amount of data.
https://www.tomshardware.com/reviews/best-ssds,3891.htmlThe thing with what you've mentioned above, needs to be put in perspective.
First, follow the link above and look at the ratings on all the best drives on the 2021 list -- the vast majority of them have *up to 1200 TBW* as their rating. That's only a third of what you're calculating for. Instead of 0.98 TB daily use (which I have no idea how you calculated that number), you're looking at 0.65 TB daily use of a 5 year lifespan. (1200 TB / 365 days / 5 years.)
(Also notice that there are several of the best rated drives on that list with only a 600TBW rating. Samsung 980, WD Blue SN550... That's half the 0.65 above, and one-sixth of the rating as on your drive.)
Now 0.65 TB *seems* like a lot, but let's take a moment to look at an interesting feature of QB64's -- the undo feature.
Do you know how undo works in QB64? I'm not 100% positive, but I *think* it's a very simple method of "write your program file over and over to disk"
For example, here's my program: PRINT "HELLO WORLD".
Undo will write an entry: P
the next entry: PR
the next entry: PRI
the next entry: PRIN
the next entry: PRINT
the next entry: PRINT "
the next entry: PRINT "H
the next entry: PRINT "HE
Each time you type a key, your whole program gets dumped to disk, so that when you hit CTRL+Z, the IDE can cycle back to the previous program state. And this is with *EACH AND EVERY KEYPRESS*.
Add to the fact that undo doesn't just record you current program's data, but also PREVIOUS programs data, up to the size of the undo buffer.
And what's the default max size of your undo buffer? 100 MB.
For the first 100MB of usage, your drive might append the data to the end of itself, not doing any overwriting, but what happens after you hit that 100MB size limit? Old data gets deleted. New data gets inserted... How's your drive handling that? Do you know?
I honestly don't have a clue, but if it's writing a 100MB undo file with each and every keystroke or mouse event I make in the IDE, then I can tell you, it's not going to take too many keypresses to hit 650 GB a day.
Writing a 100MB undo file, plus writing your whole program translated from BAS to C, with every input event leads me to thinking, "
I may be old skool, but all that really doesn't sound too healthy for my SSD lifespan."
There's a lot that goes on behind the scenes with my PC that I'm not completely aware of, but there's one thing I'm certain of with QB64, and that's that if we ignore undo and its mysterious storage behavior completely, we *still* translate BAS to C with every input event -- and since it's machine translated, it's NEVER pretty.
A thousand line QB64 program might break down to translate into a 10,000 line c program... which is written to disk with *each and every* input event.
Add a line into that code:
IF foo THEN END
You just wrote 10,000 lines of c to your drive 15 times! And that's not counting typos, backspaces, or edits! Adding that ONE line into your 1000 line program just wrote 150,000 lines of c code to the drive! And what if you're the guy who, like me, works with 10,000+ line QB64 BAS files to begin with? How large is the c translation I'm tossing to disk with every keystroke??
Now, at that rate, how long will it take you to reach your 650 GB drive rating in a day? Do you *really* want that type of action on your SSD?
Personally, I don't. That's why I have 128GB of ram, with 64GB partitioned for a persistent RAM drive, and QB64 stays on it where it can write to memory all it wants without burning a hole in my drive.
