Re: Observations

[Jody Goldberg <jody gnome org>]

On Fri, Dec 14, 2001 at 06:43:07AM +0800, Bill Kenworthy wrote:
> 1) Gnumeric is SLOOOW compared to excel on the same machine (dual boot)
I assume you mean slow to import.  This is probably true.  We have
made no attempts to optimise the text importer yet.  It is almost
certainly not an impossible or time consuming problem, 1 week of of
development should be enough to make it more appealing.  We're just
waiting for the author of that piece to get some time.  This would
make a good project for someone.

> 2) If a column is selected (click on header) and filled (cut & Pasted
> formula), the fill goes all the way to row 65535.  The spreadsheet then
> slows dramatically as it seems to always want to calculate all 65000
This is known.  We use several tricks to help minimise recalc.  All
of them currently get shot when an entire column is filled with
data.  I'm planning 2 relatively simple changes in the data
structures that should ameliorate this.
    - Switch from allocating single cells in a hash to allocating
      ranges in a quad-tree.  Similar to the style quad-tree but
      simpler.  This would give us better bounding information.
    - Switch completely to just in time rendering.  This will
      decrease memory usage and dramaticly shrink the cost of
      filling large areas.

> rows, even though only the first few thousand rows may have real data. 
> Excel appears (?) to use "virtual" rows after the real data to avoid
> this problem - hope this makes sense!  This can be fixed by selecting
> all rows after real data and deleting them - a kludge I think.
I'm fairly sure they actually put data in there.  They just have
better heuristics/structures for managing it.

> 3) Related to 1 & 2, Gnumeric uses a lot of memory, to the point where I
> had a system crash when all 256M memory and 512M swap filled when trying
> to save a > 5Mbyte tab delimited ASCII file as a ".gnumeric" type -
> again excel just worked as expected (slow, not crash, that is!)
1) Using lots of memory, 0.7x should be pretty reasonable it has
been noticeably smaller than other Open alternatives for all my test
cases.  However, XL is still much more parsimonious about memory.
Hopefully, the just in time rendering and the cell chunking will buy
us some improvements.

2) Saving as .gnumeric still uses libxml to generate a DOM tree then
dumps it.  The is HUGELY wasteful.  It is definitely a priority to
fix that during the next dev cycle.

> 4) Gnumeric's import feature stumbles over embedded control characters
> such as NULL and \x01 - excel just loads them and goes on.  I use a
Hmm, this is trickier.  We are currently rather anal about importing
only valid chars to avoid importing a binary file.  Hopefully a
balance can be struck.

> 5) Being able to select "Treat two delimiters as one" (something like
> that) in gnumeric is not as flexible or useful as being able to "treat
> multiple delimiters as one" in excel.
File this in bugzilla.

> files instead of having to boot win! Seriously, I think that the ability
> to import through a custom filter (such as selectable filters, including
> the ability to select homebrew perl scripts working to stdin/stdout)
> would be a real benefit for specialised import problems.  Once a filter
> is written, an regular user could then just follow the instructions.
An interesting idea.  File this in bugzilla.  We'll be cleaning the
i/o plugin interface after 1.0.  I will try and remember this
suggestion in the design discussions.

Thanks for the thoughts
    Jody