Re: SSDS breaks 2GB barrier - very very slowly but only for "y" not for searching.
@BC_Programmer said:
In order to access files beyond 2GB, you NEED TO USE the Ex Functions, which use 64-bit long integers.
Visual Basic does NOT use these functions.
As much as I hate to do this SSDS did manage to read and display the last line of a 4,516,942k file on my pc here - it did however take over 15 minutes with no information whatsoever being display and had a dual core laptop running at 50% utilisation the entire time (in fact the left hand side feels warm as I am typing this). Admittedly doing a Tail-File from powershell took less than a second to return the same results though...
I can only assume the Line Input uses SetFilePointer behind the scenes. This does however mean the
only way it can read a large file is in a straight sequential order.
More worrying is the fact I then said I want to continue and typed in the search term for the very last line and it is now just printing "reading <increasing number here>" over and over again on my screen while again running the cpu at 50% solid. I can feel the laptop getting warmer as I type....
As a more typical behaviour though it did fail dismally on a one line file saved in Unicode though, in fact I could hit enter and the dialog prompted me to hit enter to continue or x / e to exit and if I hit enter I had a blank screen. All I could do was open the same hit enter to continue dialog box or exit....
The really scary thing is the fact he will claim this as a victory now - getting it to read a file so large no sane person would ever use and it taking over 15 minutes to do so despite the fact I could tail it in a fraction of a second. He will also ignore the failure to handle unicode, the failure to display anything other than "not responding" while doing so and so on.
Against my better judgement I am going to leave the search running for longer just to see how long it takes to find the end / physically damage my laptop.
EDIT: That was easy - it ran for a further 15 minutes or so and then stopped producing any output what so ever and has now dropped it's usage to a much more laptop friendly 47% of a dual core.
Based on the line number it failed on it would appear that while reading is not limited searching is limited to just under 2GB as the file was consisting of
abcdefghijklmnopqrstuvwxyz<crfl>
so at 28 characters per line it hung on line 7669000 giving approx 2,147,320,000 characters