[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]performance test / SWF ?
From: |
Thomas Fritzsche |
Subject: |
Re: [DotGNU]performance test / SWF ? |
Date: |
Thu, 9 Oct 2003 10:56:34 -0000 (UTC) |
User-agent: |
SquirrelMail/1.4.0 |
Hi Rhys and dotgnu-hackers,
good to hear that my general compute-bound aspects run "pretty good".
and I agree that speed can improved by the ways you proposed, but I have
currently a little other problem. It is that my SWF/System.Draw
applications are so slow. I compared this with Neil results from
Windows+RedHat(vmware) and for some reasons his system is more than 10
times faster. (windows even more) So this is something with my system
configuration, but dotgnu SWF is the only application I observe this. I
wrote to a linux mailinglist to get a hint, compiled different freetype
versions, changes X11 settings etc. but nothing works. Everything else is
fast as before and dotgnu is still slow as before.
Thanks and regards,
Thomas
PS.: To test the SWF speed Neil added the following lines around the
MeasureCharacterRanges in the Textbox control (in method LayoutFromText).
...
Region[] bounds;
DateTime n = DateTime.Now;
bounds = null;
for (int i = 0; i < 100; i++)
{
if (passwordChar == 0)
bounds = ControlGraphics.MeasureCharacterRanges(Text, Font,
measureBounds, format);
else
bounds = ControlGraphics.MeasureCharacterRanges(new
string(passwordChar, Text.Length), Font, measureBounds, format);
}
Console.WriteLine(DateTime.Now.Subtract(n).TotalMilliseconds);
...
> On Thursday 09 October 2003 07:21 pm, Thomas Fritzsche wrote:
>
>> Maybe this is a general problem with my dotgnu version. To check this I
>> post here my PNetMark results. (CVS 03.10.2003/AMD
>> +3000/512MB/NForce2/ATI-Radeon 9500 Pro)
>>
>> Are this good or bad results??
>
> Pretty good, I'd say, for such a high-powered AMD system. But the
> PNetMark
> only tests certain compute-bound aspects.
>
> I'm starting to suspect that the slowdown is related to garbage collection
> to
> some degree. To measure a string, it is necessary to break it up into
> sections at word/character boundaries and process the sections.
>
> Creating all those itty bitty strings and then passing them to
> "Xsharp.Graphics.MeasureString" is likely to have a big impact on the
> garbage
> collector. To confirm, you could put a counter in the "AllocString"
> function
> (pnet/engine/lib_string.c) and see how often it gets called.
>
> There are several ways this could be addressed. First, try to reduce the
> number of calls to string measurement/drawing by being cleverer about what
> you pass to the lower-level API's. The longer a string section you can
> pass
> in one hit, the better.
>
> Second, investigate modifying the toolkit API so that it passes "string,
> offset, count" instead of just "string". That way, you won't need to
> create
> a new string object to measure or draw a sub-range.
>
> The less method calls you make, and the less temporary objects that you
> create, the better off you'll be overall.
>
> Cheers,
>
> Rhys.
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers
>