[cells-gtk-devel] tree-view children

[Kenny Tilton]

Peter Denno wrote:

>On Wednesday 02 February 2005 21:16, Kenny Tilton wrote:
>  
>
>> ....
>>
>>gtk-trees should offer a GF
>>which anyone can specialize to answer the branches question.
>>    
>>
>
>Agreed, I favor the latter also. In fact, I'd not use a GF but a user supplied 
>function -- and thereby eliminate the overhead of identifying the effective 
>method. But, a GF is an OK with me if that's what you guys want.
>
A slot for a user-supplied function seems like a good idea to me, though 
for a different reason (than GF dispatch performance, which I think is 
pretty decent since most implementations optimize that nicely). I see it 
as offering more flexibility, in that different instances of the same 
class can have different functions to determine the subtrees. This 
happens also to be a nice feature of Cells: different instances of the 
same class can have different rules for the same slot.

So, yeah, go ahead and create a (what?) subtrees-factory slot. Other 
suggestions for the name are welcome.

> The construction of the trees in my application takes about 15 
> seconds. But I
>
>don't know yet where the time is going. (Is it in calls to the child method 
>or something else?)
>
Yikes. Let's take a look at this. Is this under AllegroCL? Which 
version? I have 5, 6.2, and 7. Can I just hack the tree test panel to 
add 1000 subtrees and see the same result?

As soon as I saw that 1000 number I started thinking there might be a 
problem, because all 1000 get processed into gtk objects in one shot 
just to put up the list. It would be interesting (to me anyway) to have 
a diagnostic print out the interval between the creation of each object:

(defvar *gtk-spawn-time* nil)

then somewhere where a gtk object gets created, perhaps in a new 
initialize-instance method:

      ....
     (when *gtk-spawn-time*
          (format t "~&gtk spawn interval: ~a msec for type ~a"
                (- (get-internal-real-time) *gtk-spawn-time*)
                (type-of self)))
    (setf *gtk-spawn-time* (get-internal-real-time))

I am wondering if they are all roughly 15 msec apart, or if it gets 
slower and slower over time because gtk is sorting them (or some cell 
dependency is growing exponentially).

I am no GTk programmer. Is this something (1000 list itmes) you have 
done in other Lisp-Gtk systems or from another language, and you know it 
to be fast? (Just as background--either way I would like to help you 
find a fix for this.)

> I like the cells concept, but there will always be places where for 
> reasons of
>
>efficiency or just mismatch of design, it would be good to "have an out."  
>
Sure. But I have a few optimization tricks in Cells, and more could be 
added, so feel free to check with me when you think you need an out. For 
example:

>Another place where I think I will need "an out" in my code is updating a 
>progress bar: I check the size of a hash-table to determine the size of the 
>progress bar. Its not the value in a cells slot that changes, (the value is 
>always the same hash-table) it is the size of the table.
>
Right. You would need to set up artificially a second cell slot called 
????-table-size and then increment that after each write. Then the 
progress bar can just "watch" the size slot. Cells includes a feature 
called Synapses which would let you set the sensitivity to an arbitrary 
value to avoid excessive updates.

Or do I what I did in our commercial application: since any number of 
things could be slow enough to warrant giving the user some indication 
that the app was busy working, I created a little progress-bar system. 
Come to think of it, it is pretty silly because it does not attempt to 
show actual progress, it just keeps filling and refilling the bar to 
keep the user entertained. <g> Anyway, with that I just have a 
progress-make function which I sprinkle around anywhere I suspect the 
system will run slow. If there happens to be a progress bar displayed 
somewhere, it gets a bump. If not, it is a no-op. Then any time I see 
process X is slow, I put up the progress bar before initiating X.

> And ideally I 
>wouldn't update the bar after every write to the table -- that would be too 
>often -- but maybe every 50 or 100.
>
Let me know if you need help with synapses, if you want to go that route.

> So maybe what I'd do here is use cells to 
>start and stop the periodic (by timer timeout) invocation of a progress bar 
>update process.
>
That would work. Peter, I will contact c-l.net today to see about 
getting you authorized as a Cells-gtk project admin. The acceleration 
from that black hole is getting pretty intense already. :)

kenny