I just posted a dialog demo in the MASM32 section but the code contained an algo for loading a list box that I thought someone may find useful in itself.


; ?????????????????????????????????????????????????????????????????????????

LoadListFromData proc hLst:DWORD,lpdata:DWORD

; -- --------------------------------------------------------------------
; This procedure is designed to read a list of seperate items of string
; data from the data section that is zero seperated and double zero
; terminated. It passes the start address to the LB_ADDSTRING message
; then scans the string data for the next zero seperator. When it finds
; the next zero seperator, it tests if the next byte is also a zero,
; returns to the LB_ADDSTRING call if it is not or exits if it is.
; ----------------------------------------------------------------------

invoke SendMessage,hLst,WM_SETREDRAW,FALSE,0

push esi
mov esi, lpdata

llfd:
invoke SendMessage,hLst,LB_ADDSTRING,0,esi
@@:
inc esi
cmp BYTE PTR [esi], 0 ; check for zero seperator
jne @B
inc esi
cmp BYTE PTR [esi], 0 ; check for 2nd terminator
jne llfd

pop esi

invoke SendMessage,hLst,WM_SETREDRAW,TRUE,0

ret

LoadListFromData endp

; ?????????????????????????????????????????????????????????????????????????

All speed related improvements are welcome.

Regards,

hutch@movsd.com
Posted on 2003-04-22 08:38:14 by hutch--
I would use this version, i wonder how would you like to speed up win api functions :)

LoadListFromData proc uses esi edi ebx, hLst:DWORD,lpdata:DWORD

sub ebx,ebx
mov esi,hLst

invoke SendMessage,esi,WM_SETREDRAW,FALSE,ebx

mov edi, lpdata

llfd:
invoke SendMessage,esi,LB_ADDSTRING,ebx,edi

sub eax,eax
@@:
scasb
jne @b

cmp byte ptr,al
jne llfd

invoke SendMessage,esi,WM_SETREDRAW,TRUE,ebx
ret

LoadListFromData endp
Posted on 2003-04-22 15:47:12 by bart
bart,
- Some time ago I investigated scasb/jne @b
and on PIII we have retirement problem(see A.Fog)

scasb ; 3mops
jne @b ; 1mop

(3+1) / 3 = 2 clocks
So, we can't do the loop in one clock!!!

- You can substitute SendMessage with DispatchMessage or
with direct call to the proc of hList.

Regards,
Lingo
Posted on 2003-04-22 20:36:42 by lingo12
Bart,

The only method I know of speeding up API functions is to go buy yourself a 10 gig pentium 12.

The idea with the algo was to get the API functions to read directly from the addresses in the DATA section without buffering.

Regards,

hutch@movsd.com
Posted on 2003-04-22 21:34:16 by hutch--
speed up code around API functions == silly idea. How much are yo u really going to gain from this? Using DispatchMessage might be an interesting idea, even though I doubt you'll be able to tell that much difference... and what about filling the .time and .pt fields? (you'll probably get away with not doing it 99% of the time - but what about the remaining 1%?). Calling the wndproc directly... geez. Bad idea.
Posted on 2003-04-23 02:01:37 by f0dder
I agree with f0dder here, there is not much you can do around an API call to get any reasonably speed improvement.

What I have done with the algo is to turn off the update for the listbox while it is being loaded, get the API function to read directly from the source and minimise the loop overhead to find each following zero and find the next string start.

Bart's code will be slower with scasb but loading an API is hardly fast so his version may be a small code replacement that is easily fast enough.

Regards,

hutch@movsd.com
Posted on 2003-04-23 02:17:39 by hutch--
Doing SetRedraw is a good thing (but shouldn't you do an InvalidateRect after setting SetRedraw back to true?)

Another optimization would be to do LB_INITSTORAGE when you add a large amount of strings. Of course this means you need to know the number of items beforehand, but I think that even scanning your list of items twice (one to get count of items, one to add) would be faster with the addition of LB_INITSTORAGE. I've recently done a bit of similar work with listviews, and for 10k items you can definitely feel the difference between using LVM_SETITEMCOUNT and not using it.
Posted on 2003-04-23 03:36:15 by f0dder