Cache complex list for faster performance



I'm trying to speed up the performance of a GUI application that I develop. Currently the GUI works as a front end to a command-line tool; it fires various commands to the tool, parses the output, and then displays the data in a tablelist widget. My program is slower than I'd like because it's constantly querying the command-line program for everything, including for subsets of larger data sets that it's already returned.

What I want to do is to load the entire data set/list on program startup, then parse that list as needed using my own procedures from within the GUI, so I don't have to fire commands constantly to the external tool. However, I'm not clear on how to do this.

Here's the code that fetches the entire data set:

#show all available ports
proc getAllPorts {} {
global status category portpath verboselevel portlist

clearPorts
set status "Updating package list"
showProgress
set category ""

#get all available ports
set getportlist [split [exec $portpath list] \n]

#get and parse list of installed ports
set portinstalled [split [exec $portpath installed] \n]

set installed [lrange $portinstalled 1 end]
foreach item $installed {
lappend packages [lindex $item 0]
}

#compare installed ports and list of all ports, specify which are installed
foreach item $getportlist {
set program [lindex $item 0]
set version [lindex $item 1]
set searchcategory [lindex [split [lindex $item 2] /] 0]

if { [llength $installed] == 0} {
set myinstalled ""
} else {
set isinstalled [lsearch -all $packages $program]
if {$isinstalled >= 0} {
set myinstalled "Yes"
} else {
set myinstalled ""
}
}

set portlist [list $myinstalled $program $version $searchcategory]
.t.right.upper.frame.listbox insert end $portlist

}

bell
endProgress
set status "Displaying all available ports"
}

The key variable in question here is "portlist." That's the final list that is dumped into the tablelist widget. How can I store/cache the entire contents of $portlist so that I can parse/query it as needed? If it's feasible to do this as a global variable, I haven't figured out how to do it--trying later to find "portlist" only returns the first item of the list. The list has about 4,000 items in it, each line of the list structured as {$myinstalled $program $version $searchcategory}.

Any advice is appreciated.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
.



Relevant Pages

  • Re: Random non-binding survey on naming
    ... In computers I started with command-line on a UNIVAC and a PDP-11 then when personal computers became available I used command-line, and programmed them that way, and then, when they became available, I went to GUIs, of which the Atari and Apple were the best. ... With these, also, I am glad to be able to say "I've been there and done that", but you'd need to wipe out all the GUI computers to GET me to go back. ... There are just many things that GUI does better than command-line, and the Mac GUI is overall better at than Windows, or was for many years anyway. ...
    (rec.arts.sf.composition)
  • Re: Confusing stack effects
    ... Anyway, the command-line is for maximum flexibility, not ease of use. ... What GUI _are_ is not important. ... of their design. ...
    (alt.lang.asm)
  • Re: about GUI for a existed executable program
    ... "> I'm programing a GUI for a command-line program. ... "> similar to gdb. ... "> I have been reading the source code of Insight. ...
    (comp.lang.tcl)
  • Re: Random non-binding survey on naming
    ... things that GUI does better than command-line. ... your computer as a canvas for art, GUI works better. ... GUIs are somehow incapable of reproducing text-only games. ... Which means I can't use my Apple IIe emulator to play ...
    (rec.arts.sf.composition)
  • RE: VNC Client
    ... Does anyone know how to bring this GUI back up or is there ... > the ports # you want. ... > I'm comfy with SHorewall. ... Clemson University Math Sciences ...
    (Fedora)