[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax
From: |
Ben Pfaff |
Subject: |
PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data |
Date: |
Thu, 13 Sep 2007 04:58:21 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1) |
Follow-up Comment #6, bug #20910 (project pspp):
>...Maybe just call it lazy_status_destroy...?
OK. Patch updated.
>2. It would follow the OO paradigm more closely if there was a struct
>called struct lazy_casereader, which inhereted from an ordinary
>casereader. It would need to contain extra state (what's currently in
>struct lazy_status) and would need one extra method (currently
>performed by lazy_status_destroy).
In an earlier version of the patch (that I didn't post), lazy_status
was called lazy_casereader. It still wasn't an actual casereader
though. The renaming to lazy_status was the last thing I did before
posting the -4 patch.
I would like a lazy_casereader to be as much like a regular casereader
as I could make it. Unfortunately I'm at a loss how to do a couple of
things. First, I think there needs to be something like lazy_status
that is separate from the lazy casereader. Why? Because, otherwise,
when you put the lazy casereader into the data set, how do you know
whether you got the same one back after executing the syntax? You
can't just check whether you got back a lazy casereader (there's no
reason to believe that other code couldn't put a lazy casereader into
the data set, especially since we're putting it in generic code in
src/data now). You can't compare the "struct casereader *" you put in
against the one you got out (it could be the same address but the
casereader you put in was freed and then a new one malloc'd later got
the same address). You can't clone the lazy casereader and then pass
in the clone, because cloning the casereader instantiates it.
I had at least one other problem to mention but that one seems
sufficient for now :-) Do you have an idea?
(file #13932)
_______________________________________________________
Additional Item Attachment:
File name: datasheet-speedup-5.patch Size:12 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?20910>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, Ben Pfaff, 2007/09/09
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, John Darrington, 2007/09/09
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, Ben Pfaff, 2007/09/12
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, John Darrington, 2007/09/12
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data,
Ben Pfaff <=
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, John Darrington, 2007/09/13
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, Ben Pfaff, 2007/09/14
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, John Darrington, 2007/09/15
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, Ben Pfaff, 2007/09/16
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, John Darrington, 2007/09/18
- PSPP-BUG: [bug #20910] GUI becomes extremely slow after executing syntax which doesn't read the data, Ben Pfaff, 2007/09/19