You're not saving processing power.
That's the point.
from experiance, saving things as whole pages is slow. it means that when you want to search for something you have to open a whole document and parse that document. you don't have a database so you always need to parse things (including lists of files) in memory.
I've long since put away my media player, but do you have any idea what the code is like to get a directory listing, split that into strings, store in an array, then look at file types, format to HTML put into a visual tree structure, and display different icons depending on file type? unless you're writing this with it storing to temporary files as well you need to do this all in one line.
many may years ago, I actually did exactly what you're doing, with a program in C that put an untypable character into a text file, that works well as a separator as you can use getc to load characters from the file and decide to stop when you get to the special marker char that you can use to mark column, and a char that you can use to mark ends of rows.
what you're not understanding is that, it's trivially easy to create a flat file database, but SQL isn't a flat file database, it's a relational database.
so to retrieve this post, the page isn't just loaded.
first the title page is loaded, where results are sorted by date, (though you can change the sorting if you want?) then you click on the link, where posts can be sorted by date or by reply, and can be ascending or descending, then post content is linked to the member details by use of the members unique ID.
which means that member information, (username, location post count title etc) can change easily, and be updated with every post...
the point is, I understand what you're doing, what you're doing increases RAM usage, particularly because when you get larger files they end up needing to be opened in memory, and your file stream ends up in memory, to combat this you intend to use a RAM disk? I assume that you mean a swap or page file as oppose to a ram disk/hyperdrive (
HyperOs OneClick)
as for reduced processor...
I'm not convinced about that either, it'd be interesting to see how your file based search system compares against a modern day SQL system, also interesting to see how your system compares against some older version of Oracle, or SQL server...
I don't doubt your ability to run on a credit card sized PC given the size of the raspberry pi, and it's 700MHz processor and 500 MB RAM, but how would that stack up against a system running MS SQL 6.5. that had amazing performance on 66MHz systems...
I understand what you're doing, but you're throwing a lot of expensive disk resource at slow code, that is trying to reduce processor usage where a CPU problem just doesn't exist?
Sure you'll never run MS SQL2012 on a credit card sized PC, (actually you probably could) -and you'd probably get results loaded faster than what you're doing.
but a decent light weight database server can happily run on limited resources and return results very fast.