[Bug 6936] eMule uses 40% CPU when idle permanently, independent of CPU speed

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=6936





--- Comment #28 from Keith <keith_kw_muir at blueyonder.co.uk>  2007-12-06 13:29:15 ---
(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)
}


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.