Bug in VC++ 4.0.? (CListCtrl)
Syed -- sxs296@psu.edu
Monday, January 13, 1997
Environment: VC++ 4.0, Win95
I'm developing an application which has a CListView (CListCtrl) and there's
a problem which I really don't understand (which I think is a bug - then if
it's true, I must upgrade to 4.2 *if it's fixed in 4.2 :)* ).
Here is the problem:-
The problem only occurs when I set the style to LVS_ICON. It's unnoticeable
when the number of items is small but when it's say 2000, the items are
added at slower and slower rate as time ellapses, and sometimes, when the
item number reaches say 2000, the number of items being added is like 5-10
per second.??? (The first hundredth items added is quite fast however).
It's too slow considering that it's run on Pentium 150 & 32MB RAM.
However, when the style is other than LVS_ICON, eg LVS_SMALLICON or
LVS_LIST, the addition rate is as expected and pretty constant which is
fine. That's why I think there must be something wrong which is not at my
side - but something to do with MFC 4.0??
If it's true (MFC 4.0's fault), is it fixed in MFC 4.2??
I don't think there the fault lies in my code considering the situation
above (changing style to other than LVS_ICON will produce expected result).
I also have compiled code from Jeff Prosise's book - Programming With
WIndows 95 (Wanderer from chapter 13) which implement CListCtrl much like
mine does and the code still suffers from the speed degradation that I
mentioned above.
Again, thanks for any information/pointer.
Kenneth A. Argo -- argo@rias.COM
Monday, January 13, 1997
[Mini-digest: 5 responses]
Just a guess, but since the ListView in an ICON mode uses an imageList, =
this list must be grown, which may at times require a create new - copy =
- delete old fucntion. Try pre-creating your own imagelist and passing =
it to the ListVIew. If I remember correctly you can specify how many =
images at what dimension the list should initially hold.
Ken
----------
From: Syed[SMTP:sxs296@psu.edu]
Sent: Sunday, January 12, 1997 6:33 PM
To: mfc-l@netcom.com
Subject: Bug in VC++ 4.0.? (CListCtrl)
Environment: VC++ 4.0, Win95
I'm developing an application which has a CListView (CListCtrl) and =
there's
a problem which I really don't understand (which I think is a bug - then =
if
it's true, I must upgrade to 4.2 *if it's fixed in 4.2 :)* ).
Here is the problem:-
The problem only occurs when I set the style to LVS_ICON. It's =
unnoticeable
when the number of items is small but when it's say 2000, the items are
added at slower and slower rate as time ellapses, and sometimes, when =
the
item number reaches say 2000, the number of items being added is like =
5-10
per second.??? (The first hundredth items added is quite fast however).
It's too slow considering that it's run on Pentium 150 & 32MB RAM.=20
However, when the style is other than LVS_ICON, eg LVS_SMALLICON or
LVS_LIST, the addition rate is as expected and pretty constant which is
fine. That's why I think there must be something wrong which is not at =
my
side - but something to do with MFC 4.0??
If it's true (MFC 4.0's fault), is it fixed in MFC 4.2??
I don't think there the fault lies in my code considering the situation
above (changing style to other than LVS_ICON will produce expected =
result).
I also have compiled code from Jeff Prosise's book - Programming With
WIndows 95 (Wanderer from chapter 13) which implement CListCtrl much =
like
mine does and the code still suffers from the speed degradation that I
mentioned above.
Again, thanks for any information/pointer.
=20
-----From: David Little
Are you freeing the CDCs when you are finished painting? It sounds like =
you are facing "resource starvation", and Win95 is having a hard time =
finding device contexts....
----------
From: Syed[SMTP:sxs296@psu.edu]
Sent: Sunday, January 12, 1997 5:32 PM
To: mfc-l@netcom.com
Subject: Bug in VC++ 4.0.? (CListCtrl)
Environment: VC++ 4.0, Win95
I'm developing an application which has a CListView (CListCtrl) and =
there's
a problem which I really don't understand (which I think is a bug - then =
if
it's true, I must upgrade to 4.2 *if it's fixed in 4.2 :)* ).
Here is the problem:-
The problem only occurs when I set the style to LVS_ICON. It's =
unnoticeable
when the number of items is small but when it's say 2000, the items are
added at slower and slower rate as time ellapses, and sometimes, when =
the
item number reaches say 2000, the number of items being added is like =
5-10
per second.??? (The first hundredth items added is quite fast however).
It's too slow considering that it's run on Pentium 150 & 32MB RAM.=20
However, when the style is other than LVS_ICON, eg LVS_SMALLICON or
LVS_LIST, the addition rate is as expected and pretty constant which is
fine. That's why I think there must be something wrong which is not at =
my
side - but something to do with MFC 4.0??
If it's true (MFC 4.0's fault), is it fixed in MFC 4.2??
I don't think there the fault lies in my code considering the situation
above (changing style to other than LVS_ICON will produce expected =
result).
I also have compiled code from Jeff Prosise's book - Programming With
WIndows 95 (Wanderer from chapter 13) which implement CListCtrl much =
like
mine does and the code still suffers from the speed degradation that I
mentioned above.
Again, thanks for any information/pointer.
=20
------ =_NextPart_000_01BC0172.094EF400--
It is just a guess.
I think it is a more general problem related to the algorithm of how list
control or tree control operates. It is just taking the control longer and
longer to allocate memory. As I recall MFC use the generic C-runtime routines
to do memory operations, which generally have been criticized for poor
performance under heavy use.
Clarence
--=_ORCL_1964367_0_11919701131550510
Content-Type:message/rfc822
Date: 12 Jan 97 15:32:30
From:"Syed "
To:mfc-l@netcom.com
Subject:Bug in VC++ 4.0.? (CListCtrl)
Reply-to:mfc-l@netcom.com
Return-Path:
X-Sender:sxs296@email.psu.edu (Unverified)
X-Mailer:Windows Eudora Light Version 1.5.4 (32)
Sender:owner-mfc-l@majordomo.netcom.com
Errors-To:owner-mfc-l@majordomo.netcom.com
Precedence: bulk
MIME-Version: 1.0
Syed -- sxs296@psu.edu
Thursday, January 16, 1997
[Mini-digest: 2 responses]
Environment: Visual C++ 4.0, Win95
>Here is the problem:-
>The problem only occurs when I set the style to LVS_ICON. It's =
>unnoticeable
>when the number of items is small but when it's say 2000, the items are
>added at slower and slower rate as time ellapses, and sometimes, when =
>the
>item number reaches say 2000, the number of items being added is like =
>5-10
>per second.??? (The first hundredth items added is quite fast however).
>
>It's too slow considering that it's run on Pentium 150 & 32MB RAM.=20
>
>However, when the style is other than LVS_ICON, eg LVS_SMALLICON or
>LVS_LIST, the addition rate is as expected and pretty constant which is
>fine. That's why I think there must be something wrong which is not at =
>my
>
I would like to make a correction. Actually, it's not just LVS_ICON style
that bogg down the performance. It's two :- LVS_ICON & LVS_SMALLICON.
LVS_LIST & LVS_REPORT are doing just fine.
Just want to clear out anything, here is the portion that actually does the
dirty stuff - adding the items of CListCtrl
LV_ITEM lvi;
lvi.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_PARAM;
lvi.iSubItem = 0;
lvi.cchTextMax = _MAX_NAME;
lvi.iImage = I_IMAGECALLBACK;
lvi.pszText = lplvid->szName;
lvi.iItem = nItemCounter++;
lvi.lParam = (LPARAM)lplvid;
// Add the item to the listview
if (InsertItem(&lvi) == -1)
return FALSE;
As you see here, there's nothing extraordinary here. Assigning the
appropriate fields of LV_ITEM and pass it to InsertItem function. But please
don't stop reading yet.. there are several more important things that I want
to say here...
the implementation of function InsertItem(LV_ITEM*) is as follows:-
int CMyListView::InsertItem(LV_ITEM* lvi)
{
return GetListCtrl().InsertItem(lvi);
}
the reason why this function seem so wastefull *why don't I call the
GetListCtrl().InsertItem() directly* is so that I can run the profiler and
determine which line is the culprit of the slowness of item addition. And
here's the result after profiling (I added all the items in netscape cache -
the files are well over 1000:-
14018.327 71.6 13969.495 71.4 360
CFileView::InsertItem(struct_LV_ITEMA *) (fileview.obj)
As we can see here, the culprit is GetListCtrl().InsertItem() function.. It
consumes 71.4% of the whole processing time JUST TO INSERT THE ITEM. Why is
it taking so long.???. I have no clue at all. At first, I thought that MAYBE
the sizeof user-defined 32-bit variable is too large (lplvid). Decreasing or
adding the size (by deleting or adding member of structure - lplvid) has NO
effect at all.
I base my code on Nancy Winnick Clut's MFCENUM and her code too suffers from
speed degradation when the style is changed to LVS_ICON.
I have mentioned in previous mail that Wanderer.exe (from Prosises' book -
Programmming Window 95 with MFC - chapter 13) also suffers EXACTLY the same
thing (speed degradation with style LVS_ICON or LVS_SMALLICON). No doubt
about that - it has been tested many many times. Note that wanderer.exe uses
fixed image list - that's the image is not added to list dynamically.
On the other thing, disabling the style to LVS_AUTOARRANGE (not sure the
right constant) has no effect whatsoever. As the item is added to the list,
no sorting, updating is done until the whole thing is finished.
As you can see here, I have no idea what's going on. Also, if some of you
have time, try compile either/both two of the programs I mentioned (Nancy
Winnick Clut's and Prosises') and see what's the result. Note that I'm
compiling under Visual C++ 4.0.
*Nancy Winnick's I _think_ I downloaded it somewhere from Microsoft's WIn32s
programming website*
Again, thanks for any responses.
-----From: Syed
Environment: Visual C++ 4.0, Win95
>Here is the problem:-
>The problem only occurs when I set the style to LVS_ICON. It's =
>unnoticeable
>when the number of items is small but when it's say 2000, the items are
>added at slower and slower rate as time ellapses, and sometimes, when =
>the
>item number reaches say 2000, the number of items being added is like =
>5-10
>per second.??? (The first hundredth items added is quite fast however).
>
>It's too slow considering that it's run on Pentium 150 & 32MB RAM.=20
>
>However, when the style is other than LVS_ICON, eg LVS_SMALLICON or
>LVS_LIST, the addition rate is as expected and pretty constant which is
>fine. That's why I think there must be something wrong which is not at =
>my
>
I would like to make a correction. Actually, it's not just LVS_ICON style
that bogg down the performance. It's two :- LVS_ICON & LVS_SMALLICON.
LVS_LIST & LVS_REPORT are doing just fine.
Just want to clear out anything, here is the portion that actually does the
dirty stuff - adding the items of CListCtrl
LV_ITEM lvi;
lvi.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_PARAM;
lvi.iSubItem = 0;
lvi.cchTextMax = _MAX_NAME;
lvi.iImage = I_IMAGECALLBACK;
lvi.pszText = lplvid->szName;
lvi.iItem = nItemCounter++;
lvi.lParam = (LPARAM)lplvid;
// Add the item to the listview
if (InsertItem(&lvi) == -1)
return FALSE;
As you see here, there's nothing extraordinary here. Assigning the
appropriate fields of LV_ITEM and pass it to InsertItem function. But please
don't stop reading yet.. there are several more important things that I want
to say here...
the implementation of function InsertItem(LV_ITEM*) is as follows:-
int CMyListView::InsertItem(LV_ITEM* lvi)
{
return GetListCtrl().InsertItem(lvi);
}
the reason why this function seem so wastefull *why don't I call the
GetListCtrl().InsertItem() directly* is so that I can run the profiler and
determine which line is the culprit of the slowness of item addition. And
here's the result after profiling (I added all the items in netscape cache -
the files are well over 1000:-
14018.327 71.6 13969.495 71.4 360
CFileView::InsertItem(struct_LV_ITEMA *) (fileview.obj)
As we can see here, the culprit is GetListCtrl().InsertItem() function.. It
consumes 71.4% of the whole processing time JUST TO INSERT THE ITEM. Why is
it taking so long.???. I have no clue at all. At first, I thought that MAYBE
the sizeof user-defined 32-bit variable is too large (lplvid). Decreasing or
adding the size (by deleting or adding member of structure - lplvid) has NO
effect at all.
I base my code on Nancy Winnick Clut's MFCENUM and her code too suffers from
speed degradation when the style is changed to LVS_ICON.
I have mentioned in previous mail that Wanderer.exe (from Prosises' book -
Programmming Window 95 with MFC - chapter 13) also suffers EXACTLY the same
thing (speed degradation with style LVS_ICON or LVS_SMALLICON). No doubt
about that - it has been tested many many times. Note that wanderer.exe uses
fixed image list - that's the image is not added to list dynamically.
On the other thing, disabling the style to LVS_AUTOARRANGE (not sure the
right constant) has no effect whatsoever. As the item is added to the list,
no sorting, updating is done until the whole thing is finished.
As you can see here, I have no idea what's going on. Also, if some of you
have time, try compile either/both two of the programs I mentioned (Nancy
Winnick Clut's and Prosises') and see what's the result. Note that I'm
compiling under Visual C++ 4.0.
*Nancy Winnick's I _think_ I downloaded it somewhere from Microsoft's WIn32s
programming website*
Again, thanks for any responses.
GoroKhM1 -- gorokhm1@SMTP.ATG-NET.COM
Friday, January 17, 1997
[Mini-digest: 2 responses]
Here are some ideas of possible explanation of slow InsertItem().
1. Try while bulk insertions exclude not only style LVS_AUTOARRANGE
but styles LVS_SORTASCENDING and LVS_SORTDESCENDING. Return that
styles back after the work is done. Insert items to the end of the
list. That will prevent redrawing items below the item which was
just inserted.
2. Call LockWindowUpdate() before bulk insertion and UnlockWindowUpdate()
after it. That will prevent time consuming procedure to redraw icons
in a list control.
-mg
MarkG@usa.net
-----From: tiger@flynet.de
Did you try calling
SetItemCount(nItems); < void CListCtrl::SetItemCount(int nItems) >
before you add the items ?
This Function allows a ListControl to reallocate it's memory once
rather than every time you add an item. This may speed up your code.
Frank Leuenberger
Friedlaender Weg 30
37085 Goettingen
eMail: tiger@FLYnet.de
Phone: 0551 484690
Syed -- sxs296@psu.edu
Friday, January 24, 1997
Environment: Visual C++ 4.0, Win95
I cut all the previous messages so that this email would be far easier to
read.:)
I will brief to you what was the problem:-
I try to add lots and lots of CListCtrl's items and in doing so, the rate of
item added to the control decrease mysteriously at unacceptable rate as the
item count reaches big number (400); it only occurs if I set the style to
LVS_ICON or LVS_SMALLICON. And the slopiness is very noticeable when the
item count is big - an addition of 400 items in row will cause enuff
headache to my application. Here's is the workaround that I've done to
achieve constant rate of addition. It's not so difficult as you will see:-
Before all of the items are added, the style is checked. If it's LVS_ICON or
LVS_SMALLICON, then I change it to LVS_REPORT. And before changing the
style, I SetRedraw(FALSE). One person suggest using LockWindowUpdate and
UnlockWindowUpdate combination and that doesn't suit to my taste. The reason
: it will cause little flicker when the windows updated is unlocked -
UnlockWindowUpdate :). So I use SetRedraw(FALSE) right before the change of
style and also SetRedraw(TRUE) right after the original style is set back
and the flickering goes away.
Why I use LVS_REPORT not LVS_LIST.? The reason is because LVS_ICON and
LVS_SMALLICON will only have vertical scrollbar and so does LVS_REPORT :)).
What else to say... okay one more.. still.. if there's anyone knows how to
fix this, I am very interested to hear about it. It left me wondering how
Windows 95 explorer does its work fast (adding huge number of items without
fuss). I use to think now the developer of Window 95 Explorer did the same
thing as I did :). And if that's true, then the bug is buried down in Window
95's code.
| Вернуться в корень Архива
|