On Mon, Jun 05, 2006 at 07:57:33PM -0700, Ben Pfaff wrote:
> Here's an implementation with a different interface. If you like
> it, I'll check it in. Let me know.
>
> I suppose I can use it. I'd be immediately following every call to
> casereader_seek with a call to casereader_read. In many, but not all,
> instances the GUI will be reading sequentially. So the reader will
> already be pointing to the seeked position. Will your implementation
> behave optimally in this situation?
Well, not the one I posted, but I took a few minutes to optimize
it and it should now be OK.
I figured that sequential access starting at a random position
would be the norm, hence the preference for a "seek" function.
> Also, when scrolling backwards there'll be a lot of seeking to
> 2 positions preceding the current position. Is it worth having
> some means of hinting to the casereader that the next read will
> probably be the case preceeding the case currently being read,
> instead of the following one?
>
> On the other hand perhaps we should leave such optimisations until we
> know they're justified.
I doubt the value of trying to optimize this case unless it's a
real problem. I'm not even sure what I'd do to optimize it.I suggest then that you check in your changes when you're happy with them. I'll try to get around to using it later this week. At some stage I'll run gprof over the gui and find out where the bottlenecks are; I suspect it won't be in the casefiles. The problem with GUIs is, that there is little evidence on which to base guesses of the `norm'. The GtkSheet is free to request redraws on the cells whenever and however it wants. I presume that when it asks for continuous blocks it does so in top down order (must check). But if, for instance, the data sheet is partially obscured by another window, then when that window is closed there'll suddenly be request for the data in the middle of the sequence. Also, if it asks for cells in horizonal order first, then there'll be multiple requests for the same case. Which leads me to think that the casereader_read function perhaps shouldn't increment its index --- but I'm not sure. Anyway, thanks for implementing it. Let's check it in and see how well it works. J' BTW, are you still intending to implement the case_reader_clone method as a separate exercise? -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
