Re: Best way to deal with long loops?

From: J French (erewhon_at_nowhere.uk)
Date: 01/15/05


Date: Sat, 15 Jan 2005 08:50:13 +0000 (UTC)

On Mon, 10 Jan 2005 02:55:16 -0800, "Raptor" <bogus@none.com> wrote:

<snip>

>I'm using a filestream. Now if I could just figure out why
>my file is 2-3X as large... for 50,000 nodes mine is 4.52 MB
>versus the stock routine's 1.82 MB, and they do all the font
>and other stuff as well. Except for the junk blocks, my data
>blocks look a lot like theirs.

Try pumping it out to a TMemoryStream
- use SetSize first to about 5mb
- that should minimize mucking around extending memory

That way you will be able to figure out how much time is wasted on
thousands of disk writes

Note: TFileStream is /not/ buffered

More below

>I'm writing the following record, then the fontname and node
>text:
>
>type
> TNodeSettings = record // R/W for every node.
> nsLevel : integer;
> nsImageIndex : integer;
> nsOverlayIndex : integer;
> nsSelectedIndex : integer;
> nsStateIndex : integer;
> nsChecked : boolean;
> nsExpanded : boolean;
> nsSelected : boolean;
> nsAllowGrayed : boolean;
> nsReadOnly : boolean;
> nsData : pointer;
> nsNodeType : TDCNodeType;
> nsColor : TColor;
> nsState : TCheckBoxState;
> nsFontColor : TColor;
> nsFontStyle : TFontStyles;
>end;
>
>I seem to be writing a bunch of normal-sized blocks, with
>text and fontname and this record taking up about as much
>space as I'd expect, then a long line of apparent trash is
>thrown in. Yet I'm reading it perfectly, with all the node
>attributes working great.

I am not sure about the 'trash'
- my hunch is that it is the 'Inherited' savetostream
- not sure at all

Are you sure that your routine is really like theirs ?
I would have expected them not to store 'default' values

Also :
   TNodeSettings = PACKED record

When writing records to file it is a bad idea not to specify 'packed'
as you land up writing filler bytes of garbage between valid record
fields
- a waste of space
- and very confusing when examining the data on disk.



Relevant Pages

  • Temporary lock-up under heavy write, MegaRAID RAID-5
    ... LSI Logic MegaRAID 320-1, 64MB cache ... when writing very large files. ... disk write access, actually). ... The RAID controller is currently set to "write-through". ...
    (Debian-User)
  • Re: X-CD Roast question again please
    ... Using generic SCSI-3/mmc CD-R driver. ... Disk sub type: Medium Type A, ... ATIP start of lead in: -11318 ... writing 152 KB of pad data. ...
    (RedHat)
  • Re: efficacy of Linux w/o swap
    ... | Caching is supposed to happen, and this does not affect performance. ... that the impact starts to degrade the writing process itself. ... | Writing directly to disk will substantially decrease performance. ... Performance for the first 3/4 of an IDE disk ...
    (comp.os.linux.development.system)
  • Re: Best way to deal with long loops?
    ... all disk access is 'expensive' ... but with a smarter descendant of TFileStream ... Writing these out from scratch. ... I expect the stock TTreeView is storing data rather differently ...
    (alt.comp.lang.borland-delphi)
  • Re: dvd writer not writing
    ... To use them as HUGE flopiies, you need a packet writing program like ... > other with just a number on each disk with 4x as part of the number. ... > gig DVD-r's could be used as plain old HUGE data disks. ...
    (microsoft.public.windowsxp.newusers)