dotgnu-general
[Top][All Lists]
Advanced

[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
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]