|
![](/i/fill.gif) |
Darren New wrote:
> I'll give that a go and let you know. I'll try to make it more convoluted.
OK. Now when it starts, it's about 6.9 meg. As you move the mouse around the
UI and it highlights different stuff and pops up tooltips and such, it
drifts up to about 7.2 or 7.4 meg. If you start the code here, it pops up
to 10.25 meg and stays there. When the routine returns, it holds about 10.20
meg, so it isn't doing a GC at the end. It probably schedules a GC after so
many allocations or so many function entries or something; that's usually
how these things are set up. If it does a GC and finds it doesn't reap
much, it turns down how often the GC runs.
I compiled these as separate projects, so they're only combined at the point
where you actually run them (i.e., dynamically linked), so I'm pretty sure
there's no unexpected optimizations going on. (Honestly, I can't even figure
out how much garbage there is after each cycle, so ... ;-)
private void button6_Click(object sender, EventArgs e)
{
byte[] outer; byte[] outer2;
Fozz f; Fozz g;
for (int i = 0; i < 1024 * 1024 * 200; i++)
{
outer = new byte[8192];
byte[] inner1 = new byte[8192];
byte[] inner2 = new byte[50190];
f = new Fozz(inner2);
for (int j = 0; j < 1024; j++)
{
outer2 = new byte[30000];
g = new Fozz(f);
f = new Fozz(outer2);
outer2 = g.thingie(2);
f = new Fozz(g.thingie(1));
}
}
}
Separate assembly:
public class Fozz
{
byte[] save;
byte[] also;
public Fozz(byte[] incoming)
{
save = incoming;
also = (byte[])incoming.Clone();
}
public Fozz(Fozz f)
{
save = (byte[])f.save.Clone();
also = (byte[])f.also.Clone();
}
public byte[] thingie(int x)
{
if (x == 1) return (byte[])save.Clone(); else return also;
}
}
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |