REM wrote:
>>ms <(E-Mail Removed)> wrote:
>
>
>>Thanks, Art. But I'm interested in smaller increments, 1,2,4, to at most 10 MB
>>generated flles. I could never duplicate REM's results before. Editpad for him
>>worked on large files, mine choked over about 800 KB. My registry keeps changing,
>>so I want to run tests later.
>
>
> Mike: Note the utility I listed creates all files at the same time.
> There are 1, 2, 5, 10, 50, 100 meg files and one with a million
> characters without any line breaks.
>
> You can delete whatever you want. Just make sure you have the drive
> space available.
>
> I had 256 megs of ram on that test machine. Any quality program
> 'should' open the 100 meg file if you have that much free ram. If not,
> the swap file is used and that's a pretty slow operation.
>
>
>
Thanks, REM. Mine has 96 MB RAM. Dunno if that's a reason, but Edxor is the only
editor I can use on files of 1.5 MB or so. My old favorite, Editpad Classic,
started to choke over 900 KB.

Mike Sa

Frank Bohan wrote:
> "K3" <k3@(86_THE_SPAM)maine.rr.com> wrote in message
> news:(E-Mail Removed)...
>
>>Mark Carter wrote:
>>
>>>I want to test out a hard disk by generating a large file (let's say
>>>20Gb) to it. I don't care what its contents actually are, it could be
>>>random as far as I can.


> Have a look at:
>
> Dummy File Creator -- it works fine on XP SP2 :
> http://www.mynikko.com

Thanks. I tried it, and it works! It is suitable for creating files of
at least 20G in size, and comes with a convenient GUI.

On Wed, 26 Jan 2005 11:29:38 -0600, REM <(E-Mail Removed)> wrote:

>I had 256 megs of ram on that test machine. Any quality program
>'should' open the 100 meg file if you have that much free ram. If not,
>the swap file is used and that's a pretty slow operation.

Editors don't necessarily require much ram since they can work with
file pointers and short (maybe only 50k or 100k) sections of a file at
a time. Editing (writing) is done with multiple filing operations.
Thus, large files will take noticeable editing time, not because of
the use of the swap file, but simply because the large file is being
re-pieced together when additions or deletions are made.

File viewers can view any portion of really huge files seemingly
"instantly" because of the use of file pointers. They requre
insignifcant ram.

A truly "quality" editor would handle small and medium sized files up
to several tens of megs in size in extended memory up to the point
when the file has to be re-written (when done editing it). It would
be smart enough to handle huge files using pointers and filing methods
so it could handle files of any size.

But there's no way around having to re-write a file that's been edited
<smile>, and that takes noticeable time with huge files.


http://home.epix.net/~artnpeg

> Art <(E-Mail Removed)> wrote:

>> REM <(E-Mail Removed)> wrote:

>>I had 256 megs of ram on that test machine. Any quality program
>>'should' open the 100 meg file if you have that much free ram. If not,
>>the swap file is used and that's a pretty slow operation.

>Editors don't necessarily require much ram since they can work with
>file pointers and short (maybe only 50k or 100k) sections of a file at
>a time. Editing (writing) is done with multiple filing operations.
>Thus, large files will take noticeable editing time, not because of
>the use of the swap file, but simply because the large file is being
>re-pieced together when additions or deletions are made.

>File viewers can view any portion of really huge files seemingly
>"instantly" because of the use of file pointers. They requre
>insignifcant ram.

>A truly "quality" editor would handle small and medium sized files up
>to several tens of megs in size in extended memory up to the point
>when the file has to be re-written (when done editing it). It would
>be smart enough to handle huge files using pointers and filing methods
>so it could handle files of any size.

In the test, I loaded up to 100 meg files and looked for "The End,"
which ends each of the test data files. There were very few that could
find the end, even when scrolling. The best, EditPad include, would do
so.

>But there's no way around having to re-write a file that's been edited
><smile>, and that takes noticeable time with huge files.

True. I think some of the utilities to cut columns and such that were
suggested are valuable assets. Anything to trim the working data down
some helps.

I haven't tried, but I don't think any editor I tried could
successfully open, edit, and save a text file in the gig arena on the
machine I was using. I've got a new machine. I'll try some larger
files and see how it does.



--
Pricelessware:

http://www.pricelesswarehome.org

On Wed, 26 Jan 2005 15:55:40 GMT, Art <(E-Mail Removed)> wrote:

>I got interested in this, and I've put together a small utility which
>creates a text file in 10 million byte (decimal) increments.

This small utility I named D-BENCH is now up at my completely
redesigned web site.


http://home.epix.net/~artnpeg