aMule Forum
English => en_Bugs => Topic started by: skolnick on September 26, 2008, 02:41:47 AM
-
Hi!
I just installed aMule SVN from sept 22 2008, and I find its network performance is great. It connects way faster than even aMule 2.2.2 to both, ed2k and kad. Thanks for that. However, I also noticed that tables rendering is really slow (downloads, uploads and shared files). it takes a huge amount of time to scroll down my list of downloads (OK, there are like 900 of themm almost all paused, but aMule 2.2.2 had the same downloads and it wasn't this slow). It happens the same with uploads. I usually hide the uploads part (via the green button that hides that part) but if I click the button to show them, it appears, but it takes long time to show the just 6 uploads I regularly have. Not to mention the 2 minutes it takes to change from transfers to shared files (158 shared files) and the painful slowness when scrolling the shared files. Again, with aMule 2.2.2 this worked fine.
I'm using fedora 9 x86 fully patched, wxGTK provided by fedora (2.8.7) and aMule monolithic. The computer is an athlon x64 5600+ with 2GB RAM.
Thanks!
-
i mentioned this a while ago, and got told it was because i compile with optimize off,
but tbh every aMule svn i build now i use (for good backtraces) debug on, optimize off, and run in an gdb environment
i haven't noticed painfully slow rendering of menus in latest builds though.
on arch linux wx 2.8.8
-
I am using amule compiled with --enable-optimze, --disable-debug and the binaries are stripped. I have no clue how can i optimize it further.
Regards.
-
could be 2d driver performance, you use ati?
-
Could you try this patch (http://forum.amule.org/index.php?topic=15617.msg83793#msg83793) and see if it helps ?
-
Hi!
I am inclined to the gav616 option, since I use F9 and nvidia, and because of livna system being down I have not been able to install the latest nvidia driver on my system, therefore I am using the standard 2d nv driver for my card. That should be the cause. I'll wait for livna driver and test again. However, the sturedman's patch seems interesting...what should it do, stu?
Regards.
-
Right now the progress bars are rendered with high level graphic functions DrawLine/DrawRectangle which use pens and brushes. The patch renders the whole bar into an array and draws it as a raw bitmap all at once. This does away with the GDI ressource problem on Windows and also improves performance. How much should depend on the performance of the DrawLine/DrawRectangle functions - it could be more on some platforms than on others. Especially if there's no hardware drawing support as in your case.
You can try disabling progress bars for a start. If that increases your performance dramatically the patch should help as well (with bars back on of course).
-
sturedman:
Is there any loss in committing your patch to SVN? will it be commited?
Regards.
-
Hi!
I installed sturedman's patch, and 5 minutes after using aMule, it shows no slowness at all. In fact, it works as good as when I had my nvidia drivers installed. So far, i like this patch. I think it should be commited, since it seems the patch removes aMule's dependance on a properly working video driver and it makes it work using a plain VESA video driver. I'll keep you informed on any new events...
Thanks!
Edit: After running for more than 8 hours, aMule is still completely responsive, and even faster than ever was. The sorting of the tables is now as fast as emule on windows (a breeze), which is really good. I love this patch.
-
It will most probably be commited, it's my fault it hasn't been yet. But it will.
-
Thanks Kry. This seem to address one of the complains I had with aMule: the GUI was slower than the emule one.
Regards.
-
Patch is in SVN now (already in the snapshot Wuischke posted (http://forum.amule.org/index.php?topic=16043.0)).
-
Great sturedman, thanks a lot!