CODEWITHSUNDEEP
.netdatabasememorymemory-management
Chibueze Opata
Chibueze Opata

Reputation: 10054

Using string resources over database in c#

I have run across many cases where I just want a simple database that contains about 500 - 1000 strings, each of about 100 characters without the need of updates, and mostly I end up using databases. So suddenly I'm wondering if I could just use string/text file resources instead. Has anyone tried this before? I'm assuming this should be faster than a normal physical database, but I'm wondering what the memory implications/performance costs will be like. Any advice? Thanks.

Upvotes: 0

Views: 414

Answers (1)

Ben
Ben

Reputation: 6059

That depends on how the strings are used. If they will never change and are never exposed to the user, then setting them as constants in the code itself is sufficient. The memory burden here would be minimal.

If these are labels or messages that users will see but won't be updated by the application, then string tables are appropriate. This also allows you to localize your application in the future. The memory required here will be at least as much as the string constants, plus some overhead for the plumbing built in by the resource framework.

If these strings will be updated by the application (or its users), you'll need to make provisions in your code for this by storing the strings externally - whether in a database, in an XML file that you (de)serialize, a plain text file, or by some other means. It's harder to talk about the memory burden here, because you have so many different implementation options.

As to the memory burden of these strings: you've stated that you'll have (at most) somewhere around 1000 strings. Let's be generous and call it 1500, just in case. Each string will be around 100 characters long. Characters in .NET are UTF-16, meaning that each takes two bytes. With these assumptions, we can say that your strings will occupy at least 300,000 bytes - approximately 300 KB, allowing for the memory taken by the string objects themselves. Given that you're using the .NET framework, this kind of memory generally isn't worth quibbling over.

EDIT: Performance implications

Think about how much work your CPU does for each of the above.

With constants, it's basically loading a pointer.

With files, you're now talking about loading a filename, instructing the OS to open a file, reading its contents into memory, processing the contents, and finding the string you want. That's a lot more work!

Now imagine what might be involved simply connecting to a database, let alone getting information out of it.

You'll never beat constants for speed. Databases will certainly be orders of magnitude slower, and shouldn't be considered unless you really need their features. Working with files is much faster than working with databases, but still slower and more error-prone than using constants.

Upvotes: 1

Related Questions