One of the biggest problems today is that damn slow file system and windows registry, the NTFS file system is good when you work with a small amount of files, and once you have more files, it becomes slower and slower.

And the same applies to the Windows Registry.

It would be wonderful if the SQL Server 2005 everywhere edition is provided as a low level Windows Kernel API, so instead of using a prehistoric NTFS file allocation table for the file system, Microsoft will use the sql server to store the list of files and folder.

I am not talking about the data itself, it can stay as it is today, do not repeat the insane WinFs mistake for the third time, just the list of files and folders, the registry entries, the event log, etc, all the things that are based on an outdated slow prehistoric legacy code, just have them in the SQL Server Everywhere Edition, and the performance will skyrocket, just every other application running under windows will improve.

If this happens, things like Slow VS.NET issues, Slow Windows Vista RC1, and other slow Microsoft products will just become faster again.

Well, just a wish, perhaps we need 10 additional years until the microsoftians get it :-)

Hi GT,

can you add any proof for your statement of NTFS being slow. With how many files is NTFS becoming slow? Have all files to be in the same directory or does it also happen when you organize them in folders? How do you measure? I hope it is not by using Windows Explorer or any other UI tool to look at a folder with a few thousand files, because that of course is expected to be slow because Explorer reads part of the files to display icons and the various columns you can make visible like time stamps, version information... Can you confirm that CreateFile/CloseHandle gets slower when you get from 1000 files to 10000, 100000, 1000000...?

--
SvenC

Well, it is simple

If you ever used windows, there is something there called search, click on it and try to list all the files with a specific name, I am not talking about the contents, I am talking about the file names, the one managed by the file system.

ahh, if you ever used the command line, yes it is the black window with the funny text, use the DIR command there to find a file in windows (using the file name, not the contents).

as more files you have, as slower the process is, and that is just for the file names.

now create a SQL table, put a million records (file names for example) there, index it properly, and run a query; oh yes, the results are instant.

searching for a file name can take forever, and as bigger the file system is as slower the process is, unless you are using mac, you know what I am talking about,

copy 100 mb file to a folder, and then copy 100 files each of them 1 mb to another folder and find the difference, yes it is slower, copy 10,000 files with the total size of 100 mb to another folder and monitor the difference)

more files, even if the same size = longer for the operation to take, if that does not ring something, I don't think there is anything else left to say.

ah, get a million files in a folder, and delete them, 2 or 3 days maybe :-)

get a million rows in a table, and truncate it, 1 mili mili second? or less.

one day the Microsoftians will learn how to write software, and until this day comes, we will all suffer :-)

I wish if Google or yahoo, or whatever popular search engine out there releases a file system for windows, with more integrated search capabilities, then you will see everyone running in Microsoft and trying to find what went wrong, what did they miss, why did it happen.

It happen with the windows desktop search vs Google desktop, it happened with IE vs Netscape and fire fox, etc etc etc.