15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


LoadBarState and SaveBarState speed problem

Hulemannen -- elg2@nobipol.unit.no
Thursday, July 25, 1996

Enviroment: WinNT 3.51 and VC40

I use LoadBarState and SaveBarState to save and
restore toolbar settings between sessions.
Evereything works fine but after a while my program
gets more and more sluggish(starting takes half a
minute) and debugging has proven that these two
functions are the culprits. These two write to the
registry and deleting the entries they make there,
makes the program run at "normal" speed for a while
again.
-- 
Name: Steinar M. Elgsaeter (The Caveman)
E-mail: elg2@nobipol.unit.no
"The nice thing about C++ is that only your friends 
can handle your private parts."



Dan Kirby -- dkirby@accessone.com
Sunday, July 28, 1996

[Mini-digest: 4 responses]

There are problems with the LoadBarState and SaveBarState with 4.0 and 4.1. 
 All of the problems should  be fixed in VC++ 4.2.  The problems is that 
you would see the .INI file growing after each time the program was 
executed.

--dan

----------
From: 	hulemann[SMTP:elg2@nobipol.unit.no]
Sent: 	Thursday, July 25, 1996 2:31 PM
To: 	mfc-l@netcom.com.
Subject: 	LoadBarState and SaveBarState speed problem

Enviroment: WinNT 3.51 and VC40

I use LoadBarState and SaveBarState to save and
restore toolbar settings between sessions.
Evereything works fine but after a while my program
gets more and more sluggish(starting takes half a
minute) and debugging has proven that these two
functions are the culprits. These two write to the
registry and deleting the entries they make there,
makes the program run at "normal" speed for a while
again.
--
Name: Steinar M. Elgsaeter (The Caveman)
E-mail: elg2@nobipol.unit.no
"The nice thing about C++ is that only your friends
can handle your private parts."




-----From: Roger Onslow/Newcastle/Computer Systems Australia/AU

There is a bug in MFC save/restore of bar states
Here is a fix (not sure where it came from now -- think from MS KB somewhere)
Include this static routine in the .CPP where you SaveBarState...

======================================================================
#if _MFC_VER == 0x0400 || _MFC_VER == 0x0410
static void CleanUpControlBarState(CDockState& state) {
    for (int i = 0; i < state.m_arrBarInfo.GetSize(); i++) {
        CControlBarInfo* pInfo1 = (CControlBarInfo*)state.m_arrBarInfo[i];
        for (int j = 0; j < state.m_arrBarInfo.GetSize(); j++) {
            if (i == j) continue;
            CControlBarInfo* pInfo2 = (CControlBarInfo*)state.m_arrBarInfo[j];
            if (pInfo1->m_uMRUDockID == pInfo2->m_nBarID) continue;
            int nSize = pInfo2->m_arrBarID.GetSize();
            for (int k = 0; k < nSize - 1; k++) {
                if ((LONG)pInfo2->m_arrBarID[k] == (LONG)pInfo1->m_nBarID + 
0x10000) {
                    pInfo2->m_arrBarID[k] = NULL;
    }
            }
        }
    }
    for (i = 0; i < state.m_arrBarInfo.GetSize(); i++) {
        CControlBarInfo* pInfo = (CControlBarInfo*)state.m_arrBarInfo[i];
        int nSize = pInfo->m_arrBarID.GetSize();
        for (int j = 0; j < nSize - 1; j++) {
            if (pInfo->m_arrBarID[j]==NULL) continue;
            for (int k = j + 1; k < nSize; k++) {
                if (pInfo->m_arrBarID[k]==NULL) continue;
                if (pInfo->m_arrBarID[k]==pInfo->m_arrBarID[j]) {
     pInfo->m_arrBarID[k] = NULL;
    }
            }
        }

        while ((nSize!=0) && (pInfo->m_arrBarID[nSize-1]==NULL)) {
            nSize--;
            pInfo->m_arrBarID.RemoveAt(nSize);
        }
        if (nSize) pInfo->m_arrBarID.InsertAt(nSize, (void*)NULL);
    }
}
#endif
======================================================================

Then when saving, instead of:
  SaveBarState("xxxx");
do this:
  CDockState state;
  GetDockState(state);
#if _MFC_VER == 0x0400 || _MFC_VER == 0x0410
  CleanUpControlBarState(state);
#endif
  state.SaveState("xxxx");

Should fix it all up

Hope this helps
           /|\        Roger Onslow
      ____|_|.\       ============
    _/.........\Senior Software Engineer
   /CCC.SSS..A..\
  /CC..SS...A.A..\   Computer
 /.CC...SS..AAA...\       Systems
/\.CC....SSAA.AA../            Australia
\ \.CCCSSS.AA.AA_/
 \ \...........//      Ph: +61 49 577155
  \ \...._____//      Fax: +61 49 675554
   \ \__|_/\_//    RogerO@compsys.com.au
    \/_/  \//

-----From: Don.Irvine@net-tel.co.uk

There was a problem with LoadBarState/SaveBarState in MFC4.0 which caused an
additional entry to be saved each time. I believe it was fixed in MFC 4.1
[certainly doesn't happen to me now].

This was discussed in this list a few months ago - you might want to take a
look at the list archive, I think a solution for MFC 4.0 was posted.

Don
-----From: ktm@ormec.com

[[ Steinar M. Elgsaeter writes that LoadBarState and SaveBarState (which 
write to the registry) are slow on his WinNT 3.51 / VC++4.0 system. ]]

The July 1996 issue of Windows Developer Journal had an article by Paula 
Tomlinson that discussed a similar registry slowdown problem. She found:

     ...The problem was that I specified the complete registry path on 
     each call to RegOpenKeyEx(). When RegOpenKeyEx() is passed a 
     registry path containing multiple subkeys, [it] must essentially 
     perform an open operation on each subkey. Since there are 
     security checks involved in each open operation on Windows NT, 
     RegOpenKeyEx() is a fairly expensive call.

I expect that this may be your problem - LoadBarState calls 
GetPrivateProfileInt, which is mapped to a registry read (with all the 
security overhead) on Windows NT. You may have to write your own version of 
LoadBarState / SaveBarState that optimizes the number of registry calls 
(e.g. open the root key once and then look at each subkey in turn).

Windows Developer Journal has a home page at http://www.wdj.com/; you can 
order back issues online at http://www.wdj.com/biord.htm.

  Katy
----
Katy Mulvey                            ktm@ormec.com
Software Development Engineer
ORMEC Systems
19 Linden Park; Rochester, NY 14625





| Вернуться в корень Архива |