Created attachment 4350 [details]
Wine logfile of the problem.

Two details I forgot:
- I tested the Webinterface by accssing it from a machine on my LAN using Firefox2.0

- The logfile only contains information about the CPU usage problem, I did not
access the Webinterface while creating the logfile because I was using
WINEDEBUG=all and accessing the Webinterface would have created an insanely
large logfile I guess.

Please file separate bugs for separate problems.

I cannot tell whether the Webinterface problem is caused by the CPU-time problem
or not. For example it might be possible that the thread which uses to much CPU
takes the CPU-time from the Webinterface-thread. Especially because in the past
it was using 100% CPU always. Therefore I put those two problems into one report.

Besides, this is not a minor severe bug because it effectively prevents me from
using eMule:
- it slows down the whole system to an inacceptable level (because the CPU usage
is not proportional to CPU speed I cannot just install a faster CPU)
- it also prevents me from actually using my linux-box as an eMule-Server
because I cannot access eMule via Webinterface and I have no physical access to
the computer all the time. So I cannot use eMule because of the problem.

No, if program works just uses more CPU then it is on Windows - that is a minor
problem. And please open separate bug for web interface problem.

Well OK. Unfortunately I cannot edit the description anymore, only the summary.

What do you mean by "then it is on Windows"?
Running eMule on Windows uses 0% CPU when it is idle. Idle GUI programs should
not use any CPU when idle. Well the log file seems like it should be easy for
someone who knows the Wine code to identify which thread is stuck in an infinite
loop, I don't know the wine source code very well unfortunately. Would be nice
if someone could take a look :)

Ah you meant "than". Sorry my fault.

The web interface issue is already covered by bug 6415.

Are you still getting problems?

I just did a test, and I noticed that I got the same issue (about 40% CPU usage)
by eMule, however it only occured while eMule was actively hashing files.  What
happens if you reduce your share size or let it finish?

I suppose you did not actually read my bug report. The CPU usage happens when
eMule is completely *EMPTY* - no downloads, no shared files - and should be
doing nothing.

The problem persists with Wine 0.9.31.

Did you try to do some profiling to figure out where it spends it's cpu-time?
(use OProfile if possible, valgrind/cachegrind (might cause too much slowdown
though), or gprof (haven't actually tried that. Will only report time spent in
Wine but if the hog is in emule itself this can't be figured out that easily
anyway).

please keep the original version number to indicate when you first experience
the problem.

Created attachment 6511 [details]
eMule + wineserver using less CPU when the Options dialog is open

eMule under Wine uses more CPU than under Windows or a native application,
however the CPU usage is moderate when the Options dialog is open.

Created attachment 6512 [details]
eMule + wineserver hogging the system when minimized

When eMule is minimized, the CPU usage soars. Pay attention at PID=28383,
that's a low priority app that only uses idle time.

The system is an AMD64 single core 2.0 GHz, eMule and wineserver are using ~84%
vs 31%.

I can confirm the "bug" with emule 0.9.38 patched for udp packets issue
(see this: http://bugs.winehq.org/show_bug.cgi?id=5774)
and without it.

Hardware used:
PIII 500 @ 256 MB ram

With a *CLEAR* install with no file shared and no file hashing, the cpu load for
emule.exe + wineserver is about 40%, and increase when files are downloaded.

I tried it with about 40-50 files, it's stable, but the cpuload reaches 80%.
Perhaps there is to work on efficency of wine with emule... i suppose.

(In reply to comment #16)
> I can confirm the "bug" with emule 0.9.38 patched for udp packets issue
> (see this: http://bugs.winehq.org/show_bug.cgi?id=5774)
> and without it.
> 
> Hardware used:
> PIII 500 @ 256 MB ram
> 
> With a *CLEAR* install with no file shared and no file hashing, the cpu load for
> emule.exe + wineserver is about 40%, and increase when files are downloaded.
> 
> I tried it with about 40-50 files, it's stable, but the cpuload reaches 80%.
> Perhaps there is to work on efficency of wine with emule... i suppose.
> 

I'm hoping for this bug to get fixed soon but I don't understand why amule should have no problems but emule virtually the same program does.

Do you still get CPU usage issues in 0.9.49?

I was unable to find appreciable cpu usage with wine 0.9.49 and eMule 0.48a.

System specifications: 
* Core Duo - 2GHz
* Memory - 1GB
* Fresh .wine/ directory

Significant background processes:
* vmware server
* several instances of epiphany
* one instance of mozilla firefox w/ 3 tabs
* mozilla thunderbird

Even with all of these programs open, no appreciable cpu usage was noticed with the specific emule process. Peaks in process usage topped out at 5% when performing various operations with emule such as searching or checking options.

Beyond the above, nothing significant was noticed about the wineserver. It had no abnormal cpu or memory usage and was unnoticeable to the discerning eye.


Conclusion:

With the above configuration, there was no noticeable cpu usage by either emule or wineserver either while in active use or idling.

Follow up to previous comment:

I am rescinding my previous comment as I have done further testing. I only downloaded 2 or 3 files max at the time with eMule when I first tested the application. 

I have now tested with around 8 or 9 downloads and cpu usage began to spike to around 20% on average. It never reached so high as 40% though.


The wineserver however never had any appreciable cpu usage and stayed at <1% of usage the entire time.

Thus I can confirm the bug with a high number of downloads. With <5 downloads though, performance seems to be on par with the program on Windows.

- Zac

(In reply to comment #18)
> Do you still get CPU usage issues in 0.9.49?
> 

Yes. I use eMule 0.48a under Wine since version 0.9.40 and I see no improvement in 0.9.48 and 0.9.49.
The behaviour described by comment #14 is still there so I always leave the "Add new friend..." dialog box open. Here are stats from "top" (delay: 60s) :

0.9.48 - chat tab. + dialog box
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                     
 7768 jm        30  15 2602m 188m 6088 S  3.3 29.8 597:10.27 emule.exe                                                                                                    
 7772 jm        30  15 24488  21m  576 S  0.3  3.4  57:15.97 wineserver                                                                                                   
 7151 jm        25  10 19072  16m 1612 S  0.2  2.5  12:57.48 Xtightvnc                                                                                                    

0.9.48 - chat tab.
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                     
 7768 jm        30  15 2602m 188m 6088 R 10.9 29.8 597:23.04 emule.exe                                                                                                    
 7772 jm        30  15 24488  21m  576 S  9.4  3.4  57:26.41 wineserver                                                                                                   
 7151 jm        25  10 18628  15m 1612 S  0.1  2.5  12:57.67 Xtightvnc                                                                                                    

0.9.49 - chat tab. + dialog box
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                     
 9134 jm        30  15 2601m  58m 9576 S  1.8  9.3   1:40.20 emule.exe                                                                                                    
 9138 jm        30  15  4356 1980  624 S  0.2  0.3   0:21.01 wineserver                                                                                                   
 7151 jm        25  10 18220  15m 2196 S  0.1  2.5  13:13.78 Xtightvnc                                                                                                    

0.9.49 - chat tab.
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                     
 9134 jm        30  15 2601m  59m 9576 S 10.2  9.4   1:51.52 emule.exe                                                                                                    
 9138 jm        30  15  4356 1980  624 S  9.3  0.3   0:30.80 wineserver                                                                                                   
 7151 jm        25  10 17776  15m 2196 S  0.1  2.5  13:13.96 Xtightvnc                                                                                                    

(P3 1GHz, no download, uploading at 40kB/s to ~10 clients)

Hello,

well I took a quick glance on this.
The idle user interface update messages (WM_IDLEUPDATECMDUI) which happen to be in quick succession are the problem.

When the app message pumping thread is idle (message queue empty), WM_KICKIDLE is usually sent to check if idle work can be done.
If no one bothers, WM_IDLEUPDATECMDUI is sent to main window and all child frame windows.
It walks the window tree by series of GetTopWindow() and GetWindow( xxx, GW_HWNDNEXT) which call into wine server -> get_window_tree().

Because of tree structure a single top level WM_IDLEUPDATECMDUI causes several GetTopWindow/GetWindow calls leading to considerable amount of CPU load (because wine server is called each time).

When you open the options dialog, it basically sits in modal dialog loop which is handled a bit different (WM_ENTERIDLE messages are dispatched to owner indicating that child waits for messages).
WM_IDLEUPDATECMDUI (with its "costly" processing) is not dispatched in this case, leading to much less CPU load.

Regards

(In reply to comment #22)
> Hello,
> 
> well I took a quick glance on this.
> The idle user interface update messages (WM_IDLEUPDATECMDUI) which happen to be
> in quick succession are the problem.
> 
> When the app message pumping thread is idle (message queue empty), WM_KICKIDLE
> is usually sent to check if idle work can be done.
> If no one bothers, WM_IDLEUPDATECMDUI is sent to main window and all child
> frame windows.
> It walks the window tree by series of GetTopWindow() and GetWindow( xxx,
> GW_HWNDNEXT) which call into wine server -> get_window_tree().
> 
> Because of tree structure a single top level WM_IDLEUPDATECMDUI causes several
> GetTopWindow/GetWindow calls leading to considerable amount of CPU load
> (because wine server is called each time).
> 
> When you open the options dialog, it basically sits in modal dialog loop which
> is handled a bit different (WM_ENTERIDLE messages are dispatched to owner
> indicating that child waits for messages).
> WM_IDLEUPDATECMDUI (with its "costly" processing) is not dispatched in this
> case, leading to much less CPU load.
> 
> Regards
> 

Is this behaviour fixable with a patch or is it inherent fault of wine and and emule that cant be sorted?

Thank you Anastasius for your analysis, it may well be the first step in the right direction, since this bug has been first reported almost a year ago.

Hello,

--- quote ---
Thank you Anastasius for your analysis, it may well be the first step in the
right direction, since this bug has been first reported almost a year ago.
--- quote ---

Well, I noticed this bug id today, while looking for interesting bug reports ... consider yourself lucky ;-)

--- quote ---
Is this behaviour fixable with a patch or is it inherent fault of wine and and
emule that cant be sorted?
--- quote ---

Well on both systems - windows and wine/linux - the same amount of idle messages is generated (actually WM_KICKIDLE and WM_TIMER).

To compare application performance between wine/linux and Windows, I use certain performance counters in Windows which reflect some operating systems aspects better than simple "CPU load".
Namely "context switches", "context switch delta", "page faults" and "page fault deltas".

Technically Windows "cheats" when it comes to CPU load (task manager, process viewer and the like) ;-)
Many threads run for such a short amount of time that they are rarely the currently running thread when the interval clock timer interrupt occurs and
hence are not charged for their CPU time (resulting in zero CPU load).

By tracking certain performance counter values one can get a good impression what is going on under the hood ...

On Windows XP, the context switch delta ("thread activity") for emule is about 700-1200 per second with plain gui (no connections).
A lot for an "idle" process.
With a modal (options) dialog kept open, the context switch delta is usually around 650 transitions per second.

Windows makes a transition to kernel mode for each window handling call but does not seem to suffer performance-wise.
The reason is simple: on modern CPUs, ring3 <-> ring0 transitions are usually carried out by "fast" system calls (special "sysenter" instruction), causing almost no CPU load.
The wine client <-> server calls/transitions - including data transfers - are are much more "costly" (process boundaries by design) - resulting in performance penalty.

Although the amount of emule "idle processing" is somewhat questionable (that short paced idle intervals generate lots of unnecessary context switches) it is perfectly valid.

So this is actually a wine performance problem (client calling into server).

There aren't much options to fix this ... either reduce the amount of wine server calls/transitions by "caching" client calls/data (increases complexity and probably causes sync problems/race conditions) or optimize wine server code paths (difficult because process boundary remains).
Unfortunately wine optimization has much lower priority than implementing new stuff/filling gaps/fixing bugs.

Another option would be to modify emule itself.
AFAIK it comes with source code.
With the right emule code modifications it should be possible to reduce idle message processing to create less overhead (wine server calls).

Regards

Hello again,

another option would be to use a newer emule version (> 0.47c).
I fetched the 0.48a source code just to look at the usual MFC brain damage and it seems they improved the idle processing situation a bit (in my opinion not enough).
By filtering a specific amount of WM_TIMER to prevent idle processing overkill, the generated CPU load is reduced by a few points.

If you don't want to use a newer version because you have own modded/hacked emule version, you can of course "backport" the changes.
Look for CemuleApp::IsIdleMessage, only a few source lines.
Though I would recommend trimming idle handling a bit more aggressively. 

Lastly you could filter WM_KICKIDLE in wine by yourself and "eat" a specific amount using diff ticks to enforce a specific idle message rate.
Though I wouldn't really recommend this change because its somewhat intrusive and might break other applications.

Regards

(In reply to comment #26)
> Hello again,
> 
> another option would be to use a newer emule version (> 0.47c).
> I fetched the 0.48a source code just to look at the usual MFC brain damage and
> it seems they improved the idle processing situation a bit (in my opinion not
> enough).
> By filtering a specific amount of WM_TIMER to prevent idle processing overkill,
> the generated CPU load is reduced by a few points.
> 
> If you don't want to use a newer version because you have own modded/hacked
> emule version, you can of course "backport" the changes.
> Look for CemuleApp::IsIdleMessage, only a few source lines.
> Though I would recommend trimming idle handling a bit more aggressively. 
> 
> Lastly you could filter WM_KICKIDLE in wine by yourself and "eat" a specific
> amount using diff ticks to enforce a specific idle message rate.
> Though I wouldn't really recommend this change because its somewhat intrusive
> and might break other applications.
> 
> Regards
> 

My personal experience of the Emule development team is that "we don't support linux" seems to be their entire attitude. If someone from the wine team approached them that might make a difference far more likely is to approach one of the many modders to get this work done.

(In reply to comment #27)
> (In reply to comment #26)
> > Hello again,
> > 
> > another option would be to use a newer emule version (> 0.47c).
> > I fetched the 0.48a source code just to look at the usual MFC brain damage and
> > it seems they improved the idle processing situation a bit (in my opinion not
> > enough).
> > By filtering a specific amount of WM_TIMER to prevent idle processing overkill,
> > the generated CPU load is reduced by a few points.
> > 
> > If you don't want to use a newer version because you have own modded/hacked
> > emule version, you can of course "backport" the changes.
> > Look for CemuleApp::IsIdleMessage, only a few source lines.
> > Though I would recommend trimming idle handling a bit more aggressively. 
> > 
> > Lastly you could filter WM_KICKIDLE in wine by yourself and "eat" a specific
> > amount using diff ticks to enforce a specific idle message rate.
> > Though I wouldn't really recommend this change because its somewhat intrusive
> > and might break other applications.
> > 
> > Regards
> > 
> 
> My personal experience of the Emule development team is that "we don't support
> linux" seems to be their entire attitude. If someone from the wine team
> approached them that might make a difference far more likely is to approach one
> of the many modders to get this work done.
> 

this was taken from the Emule forum hope it helps

BOOL CemuleApp::IsIdleMessage(MSG *pMsg)
{
    // This function is closely related to 'CemuleDlg::OnKickIdle'.
    //
    // * See MFC source code for 'CWnd::RunModalLoop' to see how those functions are related
    //     to each other.
    //
    // * See MFC documentation for 'CWnd::IsIdleMessage' to see why WM_TIMER messages are
    //     filtered here.
    //
    // Generally we want to filter WM_TIMER messages because they are triggering idle
    // processing (e.g. cleaning up temp. MFC maps) and because they are occuring very often
    // in eMule (we have a rather high frequency timer in upload queue). To save CPU load but
    // do not miss the chance to cleanup MFC temp. maps and other stuff, we do not use each
    // occuring WM_TIMER message -- that would just be overkill! However, we can not simply
    // filter all WM_TIMER messages. If eMule is run:qning in taskbar the only messages which
    // are received by main window are those WM_TIMER messages, thus those messages are the
    // only chance to trigger some idle processing. So, we must use at last some of those
    // messages because otherwise we would not do any idle processing at all in some cases.
    //

    static DWORD s_dwLastIdleMessage;
    if (pMsg->message == WM_TIMER)
    {
        // Allow this WM_TIMER message to trigger idle processing only if we did not do so
        // since some seconds.
        DWORD dwNow = GetTickCount();
        if (dwNow - s_dwLastIdleMessage >= SEC2MS(5))
        {
            s_dwLastIdleMessage = dwNow;
            return TRUE;// Request idle processing (will send a WM_KICKIDLE)
        }
        return FALSE;    // No idle processing
    }

    if (!CWinApp::IsIdleMessage(pMsg))
        return FALSE;    // No idle processing

    s_dwLastIdleMessage = GetTickCount();
    return TRUE;        // Request idle processing (will send a WM_KICKIDLE)
}

I think the code pasted by keith that was introduced in eMule 0.48a fixes the high idle cpu usage in wine.  Under (a old version ) Xp -> vmware -> unbuntu -> wine -> emule morph 0.48a i did expiece 5% cpu usage. , was 70% before

I suggest to close this bug.  

(In reply to comment #29)
You're right: this piece of code exists in eMule 0.48a (emuleDlg.cpp).
But if you look at comment #21, you'll that I did the tests with this version of eMule (0.48a).

In other words, since you suggest to close this bug, do you mean eMule can't do better ? That I will always have to keep a dialog box open ?

For me, wasting 15% of a P3 1GHz for nothing is not negligible, even if it's less than with previous versions.

If that patch has actually been introduced in 0.48a, then it had little or no effect.

3 different users (including me) have reported CPU hogging with 0.48a, though the bug report has been originally opened when 0.47c was the most recent version.

(In reply to comment #31)
> If that patch has actually been introduced in 0.48a, then it had little or no
> effect.
> 
> 3 different users (including me) have reported CPU hogging with 0.48a, though
> the bug report has been originally opened when 0.47c was the most recent
> version.
> 


> If that patch has actually been introduced in 0.48a, then it had little or no
> effect.
> 
> 3 different users (including me) have reported CPU hogging with 0.48a, though
> the bug report has been originally opened when 0.47c was the most recent
> version.
> 

to be clear the code leuk_he posted is a change to emule and not to wine. as I understand.

According to bugzilla the patch code has been posted by you (Keith), not by leuk. And 0.48a is obviously an eMule release (wine has an entirely different numbering system)

I don't quite get it, are you confused about your own posts?

(In reply to comment #33)
> According to bugzilla the patch code has been posted by you (Keith), not by
> leuk. And 0.48a is obviously an eMule release (wine has an entirely different
> numbering system)
> 
> I don't quite get it, are you confused about your own posts?
> 

I have a thread in emule feature requests for wine compatible leuk_he posted the code there and I copied it here in the hope someone might have the knowledge to implement it in emule and thus close the bug.

Wine needs to be proactive in contacting the developers of apps and asking if they would make their app wine compatible. That is what I have been doing with my thread in the emule forum I hope this explains matters

Under Emule 49a running minimized CPU usage had spikes as high as 26% but behaviour was not greatly different from windows. It may be possible to close this bug if further testing is done to confirm its fixed. Average CPU usage was 10-12% nothing like the 40% seen before.

(In reply to comment #35)
> Under Emule 49a running minimized CPU usage had spikes as high as 26% but
> behaviour was not greatly different from windows. It may be possible to close
> this bug if further testing is done to confirm its fixed. Average CPU usage was
> 10-12% nothing like the 40% seen before.
> 

I was only downloading about 3 files as I recall so it might be a good idea to test with 8 or 9

I think this can be closed. My TOP shows eMule is using only 3% of CPU time - Celeron 3ghz. I am using Wine-1.0-rc3.

(In reply to comment #37)
> I think this can be closed. My TOP shows eMule is using only 3% of CPU time -
> Celeron 3ghz. I am using Wine-1.0-rc3.
> 

The mistake I made is that the bug only rears its very ugly head when you load Emule and it has to be something like >5 files then the CPU load goes up exponentially I was reading over 90% on 9 files.

No files downloading no CPU hit.

Ok you're right, I wasn't downloading anything.

But when I've loaded 6 files with total download speed of 87kb/s (AFAIK I need to seed to have better speed), CPU usage went up to ~17%-30% right now. It seems it depends on the download speed, because when it was at 25kb/s, CPU usage was ~11%-20%.

Hello,
a) "work-around" for high CPU usage
just open "detail" window of a file in the download order list and let it open. CPU usage will drop. (Same tip above like with "options menu")

b) second "work-around" if CPU usage is very high
Let emule sort the upload/download slots (- lower window if view is split). Press _every_ column to find the column which let emule permanently and incredible fast sorting the list.

(In reply to comment #40)
> Hello,
> a) "work-around" for high CPU usage
> just open "detail" window of a file in the download order list and let it open.
> CPU usage will drop. (Same tip above like with "options menu")
> 
> b) second "work-around" if CPU usage is very high
> Let emule sort the upload/download slots (- lower window if view is split).
> Press _every_ column to find the column which let emule permanently and
> incredible fast sorting the list.
> 

These workarounds have been known for sometime now and what we want is a fix not a workaround but with wine at version 1.0 the chances of that happening a extremely remote. I would advise everyone to use amule if possible. Emule in its present state just isn't viable

(In reply to comment #41)
> 
> These workarounds have been known for sometime now and what we want is a fix
> not a workaround but with wine at version 1.0 the chances of that happening a
> extremely remote. I would advise everyone to use amule if possible. Emule in
> its present state just isn't viable
> 

What does the version being 1.0 have to do with whether this bug will get fixed or not?

Until someone approaches the problem with some creative thinking, it won't be fixed any time soon, I recommend reading the comments by Anastasius Focht who explained why eMule is so resource-hungry under Linux.

Regarding eMule viability: anyone that uses ED2K on a regular basis knows native clients suck so bad that, besides ditching ED2K entirely, eMule is the only thing that works at acceptable speeds.

aMule 2.1.3 is a sorry excuse, given its awkward interface (just look at the search engine screenshots on amule.org!), the prehistoric set of features and the sheer amount of bugs affecting it.

OTOH version 2.2 has been utter vaporware, perpetually claimed to be on the verge of being released Real Soon Now(tm), for *over* *two* *years*, that is until a couple weeks ago. It isn't officially available through my distro yet, and I have very little faith in the developers, but I will give it a spin as soon as the new package shows up.

(In reply to comment #43)
> Until someone approaches the problem with some creative thinking, it won't be
> fixed any time soon, I recommend reading the comments by Anastasius Focht who
> explained why eMule is so resource-hungry under Linux.
> 
> Regarding eMule viability: anyone that uses ED2K on a regular basis knows
> native clients suck so bad that, besides ditching ED2K entirely, eMule is the
> only thing that works at acceptable speeds.
> 
> aMule 2.1.3 is a sorry excuse, given its awkward interface (just look at the
> search engine screenshots on amule.org!), the prehistoric set of features and
> the sheer amount of bugs affecting it.
> 
> OTOH version 2.2 has been utter vaporware, perpetually claimed to be on the
> verge of being released Real Soon Now(tm), for *over* *two* *years*, that is
> until a couple weeks ago. It isn't officially available through my distro yet,
> and I have very little faith in the developers, but I will give it a spin as
> soon as the new package shows up.
> 

Well good news is that amule 2.2.1 is out as of June 11 which fixes a ton of bugs and implements the kad features and protocol obfuscation in emule. Even less reason to worry about this bug.

Since the Wine project is about having Windows application working under linux, Wine bugs obviously do matter while the status of aMule does not.

I suggest you read my previous comment again without making personal assumptions about what is better for the end-user. Native is not necessarily better.

As for the last comment... I'm not so sure. Native is *of course* better, and indeed the only reason I'm looking at running emule on wine. amule has all the features I need but I'm getting weird and nasty system crashes very frequently when running it. I have tested and retested my hardware and that's not the cause. It just so happens that when running amule *everything* turns to custard. So why not use emule? Well if I'm going to have my system heavily overloaded just by running a windows app on wine then maybe there is another option?

I'm having trouble reproducing this bug.

Does it only happen when downloading a lot?  What do I have to do other than start a bunch of large files downloading?

Guess it depends on your definition of "a lot" :) Fast or slow makes no difference, at least in my case.

Try putting several big files (e.g. Linux CD images) and leaving it running for a couple days, you should stumble on it sooner or later. When it starts doing it, it won't stop anyway, unless it crashes first. Usually I'm not downloading files with more than some dozens of sources, that might make a difference or not.

@ Anton, native not necessarily better = a badly written application does not magically turn into a good one just because it's native. A well-written native application is expected to offer /some/ advantages over an equivalent non-native app but - depending on the metric used, the non-native app can still be better than the good, native one (e.g. set of features)

I have compiled wine 1.1.7 from source without compiler optimizations and ran emule 0.48a on it, this bug still exists, when opening some dialog like "paste 3d2k links" or options the cpu usage drops by 10 times sometimes more, regardless of number of downloads, for example, with ~50 files in the transfers list, on a P3 500 mhz, without a dialog usage is between 50-70% (wineserver+emule.exe), while with a disalog open it's < 10% all the time.

(In reply to comment #49)
> I have compiled wine 1.1.7 from source without compiler optimizations and ran
> emule 0.48a on it, this bug still exists, when opening some dialog like "paste
> 3d2k links" or options the cpu usage drops by 10 times sometimes more,
> regardless of number of downloads, for example, with ~50 files in the transfers
> list, on a P3 500 mhz, without a dialog usage is between 50-70%
> (wineserver+emule.exe), while with a disalog open it's < 10% all the time.
> 

(In reply to comment #49)
> I have compiled wine 1.1.7 from source without compiler optimizations and ran
> emule 0.48a on it, this bug still exists, when opening some dialog like "paste
> 3d2k links" or options the cpu usage drops by 10 times sometimes more,
> regardless of number of downloads, for example, with ~50 files in the transfers
> list, on a P3 500 mhz, without a dialog usage is between 50-70%
> (wineserver+emule.exe), while with a disalog open it's < 10% all the time.
> 

This is not news its well known that opening a window reduces cpu usage. It doesn't fix the fundamental problem in the way emule is designed. This bug isn't going to get fixed anytime soon if ever. The native client has just as much functionality now as emule something to keep in mind when it comes to developers time.

It _is_ news. It means this long-standing bug hasn't been fixed yet.

and btw, I do not believe that emule (especially all it's mods) is replaceable, by for example amule, amule can simply not compare, it has nothing even close to what emule is, and most certainly not even close to it's mods, it's like comparing emule plus to emule/xtreme/pp-edition, they just can't be compared at all.

that being said, I do agree that the edonkey and kademlia networks are not the best thing since DDL, however utorrent works on wine just fine, if you ask me if this little bug should be fixed, i'd say if instead of that someone is going to add DX10 support with the currently slow gui rendering performance in wine, i'd say fix the bug(S) of the program(s) first (not just this one, all programs supported by wine), but if it's the implementation of optimized gui code in wine, then yeah, i'd say no.

but that's only because I have rules, first implementation of core features, then debugging, and only then fancy stuff like DX10, after all the bugs are fixed, but wine development appears to be going in all directions at once, anyway, the devs always know what is important.

considering that emule works 90% and the fact that the bug is workaroundable, I wouldn't consider it a priority, but I do not agree with you that it needs be forgotten, wine should have 100% compatibility sooner or later, as it is trying to achieve it's goals, so I was just pointing out that the bug still exists in the latest version, and I believe this information is useful, whether it will be fixed is an another subject entirely.

I have run emule some hours using wine 1.1.26 and that problem did not happen. Can anyone reproduce the problem with the latest Wine version?

yes, I can confirm #53.  "Bug 6936" seams to be solved.

Thank you!  I had been using eMule for a while now, and it seems to perform well enough for me too - marking fixed.

Closing bugs fixed in 1.1.27.

I am suffering this bug on emule (40-80% cpu) and babaschess 4 (20%cpu). Opening options dialog reduces the cpu considerable on emule and to 2% on babaschess.

Bug #22447 seems the same as this.

wine 1.3.4

ok, I tested emule and babas on wine 1.1.26, 1.1.41 and 1.3.4. On all versions I observed the same behavior. I own core 2 duo e5300 and ubuntu maverick 32 bits. So I think there is no a regression, and the main bug was never fixed.

emule around 0-10 KB/s download rate - cpu 10%
emule around 100 KB/s download rate - cpu 50%
babaschess - cpu 20%

Opening dialog box reduces cpu consumption considerably.

emule preferences dialog open around 0-10 KB/s download rate - cpu 10%
emule preferences dialog open around 100 KB/s download rate - cpu 10%
babaschess preferences dialog open - cpu 2%

Is somebody reading this? Should I fill a new bug?