OpenDCL MEMORY MANAGEMENT ?

I'm writing a fairly complex lisp (which uses OpenDCL) and the ODCL file is very rich in controls.

And I'm testing this software and so I show and then close the ODCL dialog many times.

The first few times everything is fine, i.e. I wait 1 second from the command until the dialogue is shown.

But by repeating this operation many times, many dozens of times,
the time between the command I enter in the Acad command line
and when the ODCL dialog is shown ALWAYS INCREASES.

So much so that sometimes I have to wait up to 20 seconds before the dialogue is shown.

Each time the dialogue is reloaded:
(dcl-project-load #ddiim-prj t)

And I think it's an OpenDCL MEMORY MANAGEMENT problem

It's possible ?

There is no way to know the cause without creating a simple reproducible case and investigating it. I suggest to test with a simple dialog containing only copies of one type of control. If the problem does not reproduce, try other controls until the particular control (or controls) is identified. If it happens with any control type, then it could be a memory leak, or just heap fragmentation causing Windows to start paging to disk. There is no way to guess, it has to be investigated.

Hi Owen

Thanks for your attention.

It seems that the problem is caused by the Picture Folder...

Take a look at the attached test

Thanks, I found and fixed a small resource leak during (dcl-Project-Load). I'm not sure this leak is the one you're experiencing, but it was the only one I noticed with your test code. Please test the next development build and let me know if you notice any difference.

I loaded and showed this dialog 100 times and calculated the average time taken

and I did this 20 times

and the result is this:

average : 100
average : 100
average : 99
average : 101
average : 99
average : 101
average : 100
average : 100
average : 100
average : 101
average : 100
average : 99
average : 100
average : 99
average : 99
average : 100
average : 100
average : 99
average : 98
average : 100


and so, it seems that there is no longer any problem with the Picture Folder

but I agree with you.

There is more.

And I still don't know what it is.

I have to do more tests with other controls.

And I'll let you know

Thanks for everything

ciao

it seems that there are problems with the comboboxes too...

... try to run the attached test...

... unfortunately I can't do many tests (2500)
because after 400 or 500 tests there is a crash !

and I suppose that a crash that
more or less always happens at the same point
could depend on some memory management problem...

Thanks, I found and fixed a bigger leak in several combo types. I'll include the fix in the next release.

TAB STRIP with IMAGE LIST that does NOT contain IMAGES (tt-tab-strip-0)
number of repetitions : 5000
average list MIN : 156
average list MAX : 180
AVERAGE of AVERAGES : 170.500
AVERAGE LIST : (156 159 158 160 158 159 160 160 163 165 167 165 166 162 166 166 168 167 169 168 170 169 174 172 172 170 171 172 175 175 172 175 176 175 175 176 178 177 178 178 176 179 180 178 176 179 179 179 179 178)




TAB STRIP with IMAGE LIST that contains IMAGES (tt-tab-strip-1)
number of repetitions : 5000
average list MIN : 207
average list MAX : 237
AVERAGE of AVERAGES : 223.100
AVERAGE LIST : (209 207 207 212 208 212 210 211 217 213 213 216 216 216 218 220 221 221 219 226 222 223 226 224 223 226 227 227 226 228 225 228 228 227 231 229 228 228 230 232 229 230 233 234 234 237 232 234 233 229)


5000+5000 tests without a crash !

But however there is a little problem with TAB STRIP too !


(every number of the average list represents the average of elapsed time of 100 tests)

;   (setq  #tt-prj "tt-text-box")

(setq  #tt-prj "tt-tab-strip-0")

;   (setq  #tt-prj "tt-tab-strip-1")



;   (progn (dcl-project-load #tt-prj t) (dcl-form-show  #tt-prj "form") )



(defun :LST-NUM-AVERAGE      (l) (/ (apply '+ l) (float (length l) ) ) )



;         -         -         -         -         -

(defun :DCL-TIME-TEST ( rep-no / average elapsed-time elapsed-time-lst start )

   ;         -

   (defun :DCL-TIME-TEST-SUB ()

      (defun C:DCL-TIME-TEST/FORM#ONTIMER (/) (dcl-form-close  #tt-prj "form") )

      (defun C:DCL-TIME-TEST/FORM#ONINITIALIZE (/)   (dcl-Form-StartTimer #tt-prj "form" 10) )

      (dcl-project-load #tt-prj t)

      (dcl-form-show  #tt-prj "form")

   )

   

   ;         -

   (repeat rep-no

      (setq start (getvar "millisecs") )

      (:DCL-TIME-TEST-SUB)

      (setq elapsed-time (- (getvar "millisecs") start) )

      (setq elapsed-time-lst (append elapsed-time-lst (list elapsed-time ) ) )

   )

   (setq average  (/ (apply '+ elapsed-time-lst) (length elapsed-time-lst) ) )

   (princ (strcat "\n average : " (itoa average) ) ) (princ)   

   average

)







;         -         -         -         -         -

(defun :DCL-TIME-TEST-100 ()   (:DCL-TIME-TEST 100 ) )







;         -         -         -         -         -

(defun C:TT-100 () (:DCL-TIME-TEST-100) )







;         -         -         -         -         -

(defun C:TT-5000 ( / average average-lst count)

   (setq count 0)

   (repeat 50

      (setq count (+ 1 count) )

      (setq average (:DCL-TIME-TEST-100) )

      (princ (strcat "\nnumber of repetitions so far : " (itoa (* count 100) ) ) ) (princ)

      (setq average-lst (append average-lst (list average ) ) )

   )

   (princ "\nnumber of repetitions : 5000")   (princ)

   (princ (strcat "\n average list MIN : " (itoa (apply 'min average-lst) ) ) )   (princ)

   (princ (strcat "\n average list MAX : " (itoa (apply 'max average-lst) ) ) )   (princ)

   (princ (strcat "\n AVERAGE of AVERAGES : " (rtos (:LST-NUM-AVERAGE average-lst) 2 3) ) )   (princ)

   (princ (strcat "\n AVERAGE LIST : " (vl-prin1-to-string average-lst) ) )   (princ)

   

)

TEXT BOX (tt-text-box)

number of repetitions : 5000

average list MIN : 215
average list MAX : 243
AVERAGE of AVERAGES : 232.620
AVERAGE LIST : (216 215 217 223 225 224 224 225 225 225 225 228 226 227 227 228 230 228 231 231 232 233 233 234 234 233 234 236 234 236 238 239 238 237 238 237 239 239 238 240 239 239 240 240 243 240 241 242 242 243)

(every number of the average list represents the average of elapsed time of 100 tests)


so it seems that there is also a problem with the TEXT BOX
(in the various Filter Styles)...

I checked tt-text-box.odcl, but I did not notice any leaks. I think the effect in that case is just due to normal and unavoidable memory fragmentation, not actual leaks.

author=owenwengerd link=msg=14034 date=1716835395 wrote:
I checked tt-text-box.odcl, but I did not notice any leaks. I think the effect in that case is just due to normal and unavoidable memory fragmentation, not actual leaks.

And what about TAB STRIP ?
is it the same thing ?
However I will continue to test other controls, and will report the results ...

author=owenwengerd link=msg=14028 date=1716668153 wrote:
Thanks, I found and fixed a bigger leak in several combo types. I'll include the fix in the next release.

Interesting... after updating with the latest runtime I'm noticing dialogs with many controls including combos are snappier to open!

GRAPHIC BUTTON  (tt-graphic-button)
number of repetitions : 5000
average list MIN : 165
average list MAX : 169
AVERAGE of AVERAGES : 167.320
AVERAGE LIST : (165 165 165 166 165 166 167 169 167 165 165 167 166 167 167 167 166 165 167 165 167 168 167 169 166 167 168 169 167 167 169 168 167 169 169 168 169 168 168 169 169 168 168 168 168 168 169 169 169 169)


TEXT BUTTON  (tt-text-button)
number of repetitions : 5000
average list MIN : 144
average list MAX : 151
AVERAGE of AVERAGES : 146.380
AVERAGE LIST : (144 144 146 145 145 145 146 145 145 144 145 145 145 145 145 145 145 146 146 144 144 146 147 147 147 147 145 145 147 147 146 147 146 146 147 149 147 149 149 148 147 148 147 148 148 149 148 149 151 148)


it seems like TEXT-BUTTON and GRAPHIC-BUTTON don't have any problem...

interesting... after updating with the latest runtime I'm noticing dialogs with many controls including combos are snappier to open!

that's how it is... the problem is not completely solved, but things are certainly better!