Aspa

> Yes. This produces some interesting issues since we've seen similar errors
> in other contexts. First, it looks to me as though the technique used for
> allocation is bad; the memory is consumed even if not needed.

Well, I don't know about that since we don't know what for instance the
width and thereby the amount of memory is needed to create the full table in
a file). Evidence of memory not being consumed if not needed is the list
output, since that doesn't produce the error when this enormous widht is
chosen.


> Another thing
> is that there is no simple way to say "give me as much length as I need but
> no longer" when specifying output width, and that's what we really want.

Yeah, that would be great, but then still you've got this memory problem
when the width is to big. The Out-File seems to work in mem first and then
writes it and well...than you need a lott of it for a big table. appending it
in a file maybe is a better way, but than you can't give the width parameter.

grt
Dennis

"Alex K. Angelopoulos [MVP]" wrote:

>
> "Aspa" <Aspa@discussions.microsoft.com> wrote in message
> news:5C9BBABC-BD05-48DC-BDE3-A06328DF125A@microsoft.com...
> > With a laptop 1.8 Ghz centrino, 2GB mem, running on Vista beta2 this
> > produces
> > the same result.
> > Guess is has to do with filling up the column space to create a table with
> > the width given. using a width of 214748364 (one digit less) on the same
> > command allready creates a .txt file 1.7 GB in size (takes a while to
> > create)
>
>
> I'm using a 1.67 GHz AMD, 768 MiB RAM and get errors even when I cut it down
> by a factor of 16. This suggests the problem really is a memory error, and
> therefore system-dependent.
>
> > A list won't use up the width given because the lines aren't long enough.
> > Giving this width just results in lines not being cut off. Much less
> > memory
> > is used this way.
>
> Yes. This produces some interesting issues since we've seen similar errors
> in other contexts. First, it looks to me as though the technique used for
> allocation is bad; the memory is consumed even if not needed. Another thing
> is that there is no simple way to say "give me as much length as I need but
> no longer" when specifying output width, and that's what we really want.
>
>
>
> > I don't know if these assumptions are correct, but seems logical to me. I
> > do
> > like to know if my guess about the table width is correct and could it be
> > that a table with less characters wouldn't produce this error, but than
> > system memory would matter asswel.
> >
> > grt
> > Aspa
> >
> > "Alex K. Angelopoulos [MVP]" wrote:
> >
> >> Could I get someone else to validate errors using the maximum
> >> possible -width for Out-File when output is going to be tabular?
> >>
> >> PS> Get-Command | Out-File -FilePath c:\temp\output.txt -Width 2147483647
> >> out-lineoutput : Exception of type 'System.OutOfMemoryException' was
> >> thrown.
> >>
> >> PS> Get-Command | Out-File -FilePath c:\temp\output.txt -Width 0x7fffffff
> >> out-lineoutput : Exception of type 'System.OutOfMemoryException' was
> >> thrown.
> >>
> >> PS> Get-Command | Format-Table -Property * | Out-File -FilePath
> >> c:\temp\output.txt -Width 0x7fffffff
> >> out-lineoutput : Exception of type 'System.OutOfMemoryException' was
> >> thrown.
> >>
> >> Note that if I either explicitly use Format-List or use Select-Object *
> >> (which forces list formatting) that it works fine:
> >>
> >> PS> Get-Command | Format-List -Property * | Out-File -FilePath
> >> c:\temp\output.txt -Width 0x7fffffff
> >> PS> Get-Command | Select-Object -Property * | Out-File -FilePath
> >> c:\temp\output.txt -Width 0x7fffffff
> >> PS>
> >>
> >>
> >>
>
>
>