Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[Wenyuan G. <guo...@gm...>]

Hi Tim,

Thank you for the compliments! Although things didn't go exactly as
expected, I'm just quite happy and relieved that the new problems
could be easily solved and the performance boost I promised earlier
can be delivered.

Has anyone else tried the new program? Any feedback is most welcome!

Cheers
Wenyuan

On Thu, Jul 22, 2010 at 8:50 AM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan,
>
> This is good, careful work. I think your willingness to change your plans is
> admirable, and the half-second delay seems very livable, a big improvement on
> the previous 2s. Long live profiling! :-).
>
> Best,
> --Tim
>
> On Wednesday, July 21, 2010 06:26:11 pm Wenyuan Guo wrote:
>> Hi all,
>>
>> With more careful profiling of the program, I found my earlier theory
>> to be wrong: I thought the delay when switching resolution mainly came
>> from HDD delay. This component turns out to be minor, thanks to OS
>> caching. The following two components are much more significant:
>>
>> 1. Surprisingly, the librsvg function that determines the dimension of
>> an input SVG image file takes substantial time. I had thought that it
>> ought to be as simple as to locate the relevant strings from the SVG
>> file involving only minimum parsing efforts. In any case, I have build
>> an in-memory caching table to store dimensions of SVG files seen
>> before to minimize this performance penalty to once per file for each
>> session.
>>
>> 2. The PNG function to parse input file into SDL surface is the second
>> contributor to the delay, although smaller than 1. I have built
>> another in-memory caching mechanism for these SDL surfaces, with
>> reference copying instead of actual data copying. This assumes that
>> all loaded SDL surfaces are never modified, which seem to be the case
>> for tuxmath. This is faster and more memory efficient.
>>
>> With the additional caching, pressing F10 to switch resolution takes
>> only 0.5s, compared with about 2s before. Given this small delay, I
>> have scratched the multithreading mechanism implemented before, which
>> is no longer necessary. Moreover, the multithreading functions still
>> have mysterious bugs. There are too many rendering functions that have
>> global variable and I/O conflicts. It is extremely difficult to
>> identify all race conditions between them at this point.
>>
>> Cheers
>> Wenyuan
>>
>> ---------------------------------------------------------------------------
>> --- This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Tuxmath-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>