openoffice plugin very slow

polar
for me using firefox 3.5.16 and openoffice 3.2.1 under debian linux the zotero openoffice plugin works awfully slow. (pentium V, 2 Ghz)

In a document containing about 190 references (90 unique) it takes over 15 seconds until the "insert reference" dialog appears. Inserting the choosen reference takes additional 5 seconds.

I found a view threads from the past like: http://forums.zotero.org/discussion/2070/

Is this still the same issue?

For me it doesn't make any difference if there is an bibliography includes at the end or not.
«1
  • polar
    Updating to firefox 3.16 and zotero 2.1 didn't improve the situation. Zotero is almost unusable since it takes about halve a minute to insert or edit a reference. Sometimes nothing happens until closing and reopening document.

    Should zotero with large documents (about 100 pages) be only usable on brand new hardware?

    Firefox 3.16, LibreOffice 3.3.1, Zotero 2.1
  • polar
    I transmitted a Debug-Report (while editing a reference)
    Debug ID is D1986659789.
  • Simon
    If you can upgrade to Firefox 4, it might be faster. There are also some optimizations that we plan on making to integration. FWIW, we have greatly improved integration performance since the thread you dug up.

    I'm not sure what a Pentium V is, but the 2 GHz Pentium 4 was first released more than 10 years ago. It is 4 years older than the first Firefox release, and 2 years older than Mozilla 1.0. If this is really what you have, you might want to seriously consider upgrading.
  • Simon
    edited March 31, 2011
    I did some optimizations that should improve performance. The code is not especially well-tested, but if you'd like to give it a try (on a backup copy of your document), you can install the OpenOffice Integration Trunk XPI. Let me know if it speeds things up.
  • polar
    hi simon,
    great, I'm excited. The first invocation still needs about 15 seconds. But the following edits and inserts work fluently (3-4 seconds). Now It's really usable. Was is a bug which affected my specific configuration? Or did other people have the same trouble?

    (it's a Pentium M - (IV) not V in a thinkpad t30. Indeed, it's a couple of years old.)
  • Simon
    There wasn't really a bug, just optimizations that didn't make it into 3.5a1. In particular, we were doing a lot more round trips between OpenOffice.org and Firefox than were necessary. (We were doing two round trips per field while reading data in. With the optimizations, the number of round trips is fixed and doesn't scale with the number of fields.) We haven't seen other reports of speed issues, but I suspect that round trip times would be greatly reduced with a multi-core processor. Nonetheless, this should speed things up for everyone. As I note above, the code is not thoroughly tested, so let me know if you run into any issues.
  • hadzi
    same issues here. running on an ibm think pad t43. before all the new updates happened zotero was reasonable quick. now it is very slow, up to two minutes, and sometime nothing happens at all. as i'm working with important data i can not risk using the trunk. any idea when the optimization will be available in a stable update?
  • hadzi
    in the meantime is there any way to return to 2.0?
  • hadzi
    well i found this http://forums.zotero.org/discussion/17269/where-to-find-20-to-download/

    problem is of course that the database is not compatible anymore with 2.0 - this upgrade business is a real trap for ppl with slow computers - zotero should give a clear warning!

    is there any way to downgrade my db?
  • hadzi
    what a pain: here's the procedure for downgrading http://www.zotero.org/support/zotero_data - read paragraph 'Restoring from the last upgrade backup'
  • hadzi
    after 8 hours of hacking around downgrade is successful. please keep us (those with not so posh machines) updated when 2.1. (or 2.2.) is available with optimization...
  • Simon
    edited April 9, 2011
    You could have just downgraded the OpenOffice plugin. But the trunk OpenOffice plugin should be far faster than either the old or new plugins, and is stable as far as we know (no known regressions so far).
  • hadzi
    simon, i just tried the older openoffice plugin as you suggested. no luck there either. referencing in open office is still very slow. what is more worrying though: additionally it adds random characters to my references. so it is unusable.

    i can't risk using a trunk on 5 years worth of research data. when will this trunk be included in a stable version?

    as already written in this thread i downgraded to version 2.0. open office referencing is running fine again. only problem is that i have data, from the 23rd of march onwards (naively trusting the update when importing into zotero), which i can't import into the 2.0 version.

    as described i tried 'Restoring from the last upgrade backup', exported from 2.1 & tried to import into 2.0 - but i got an error message 'The selected file is not a supported format'.

    the only hints i found were these:
    http://forums.zotero.org/discussion/15184/the-selected-file-is-not-a-supported-format/
    &
    http://forums.zotero.org/discussion/14193/bug-report-error-in-rdf-importing-and-exporting/

    i tried to export every possible format + as discussed in the 'file is not a supported format' thread different language settings. but no luck. giving up after trying for 4 hours. any help/hints of how to get my data back into version 2.0 would be appreciated.
  • fbennett
    @hadzi, Not sure why restoring to 2.0 has to be a higher priority than going through a simpler set of steps to back up your data and at least give the trunk plugin a try. In either case you will presumably be preserving regular backups, particularly before making any changes to software. If you know that going back to 2.0 means exporting and reimporting a significant number of records, whereas going forward to the trunk plugin may give you an immediately functional setup, it would seem to be worth the few minutes it would take to try.

    Just a thought.
  • hadzi
    edited April 9, 2011
    fbenett, because i'm about to finish my work over the next 3 month & i would not really like to corrupt the document. on the trunk page http://www.zotero.org/support/dev/svn_and_trac_access#word_processor_plugins it says: "While these development versions could potentially cause corruption of Zotero fields within word processor documents, they will not cause any data loss within Zotero itself." how can i know, also when the trunk seems to be working, that there will be no regressions over the next 3 months?

    i would not like to put this document forward as a guinea pig. if regression can occur (& it seems likely given the warning messages on the trunk page) i'd rather go with a stable version over the next months, meaning either a stable 2.1./2.2. office plugin comes asap (which leads to the question when?) or i'll simply continue with 2.0. (which leads to the question of getting back my data from 2.1. into 2.0.?).

    though i'm happy to give the trunk a try & i will report back - but unlikely wanting to rely on it (given the warning messages)...
  • hadzi
    ok. i made a backup & installed the open office trunk: it is still slower than 2.0! first attempt a minute, second reference 90 seconds, then quicker about 30 seconds for each reference.

    nevertheless what is the bigger problem here is that many reference fields definitively get corrupted, in about a 10th of the fields within the document i get characters added to the year like 'ap', 'j', 'e', etc. so this trunk is definitively a 'no go' for now.

    leaving me with 2.0 for now & the question of how i get my data back into 2.0 (stuff i have been adding to zotero from the 23rd march onwards), because of this error msg (as described earlier): 'The selected file is not a supported format'. again any hints/help appreciated on this one - or i'll have to bite the bullet redo the last 3 wks again...
  • adamsmith
    sort by date added, export as Zotero RDF and re-import.
  • hadzi
    adam, thank you for replying, but problem is that when trying to re-import i get the error msg 'The selected file is not a supported format'

    & as stated above the only hints i found for a possible solution were these:
    http://forums.zotero.org/discussion/15184/the-selected-file-is-not-a-supported-format/
    &
    http://forums.zotero.org/discussion/14193/bug-report-error-in-rdf-importing-and-exporting/

    but no luck so far...
  • adamsmith
    split the RDF output into smaller parts (i.e. for 5 or 10 items at a time) and see if the problem is one particular entry or the general output. If it's the former you're probably best of just adding this again manually.
    If it's the latter, create an error report ID and paste the RDF of a singe entry that doesn't work to gist.github.com, create a public gist and post the URL here.
  • hadzi
    thank you.
    unfortunately it is the latter.
    report ID is 631868291 & public gist url is https://gist.github.com/911719
  • Simon
    You may need to reset your translators and styles in the Advanced pane of the Zotero preferences.
  • hadzi
    simon, yes this did the trick. thank you very much for your support. back on zotero 2.0 & everything is working smoothly again. looking forward to upgrade once i finished my document...
  • michopop
    "The trunk contains experimental code under active development, and you may experience data loss at any time while using trunk XPIs. You will likely not be able to revert to earlier XPI releases using the same data."

    In my case it was always slow, so the downgrade won't be a solution for me. On the other hand this "trunk"-option sounds quite scarry... Has anyone tried this yet?
  • adamsmith
    the trunk Ooo plugin will only affect your document - it will not not affect your Zotero data itself, nor Zotero data. You can just try it out on a copy(!) of your document without any risk.
  • dstillman
    michopop: That's about the Zotero client trunk XPI. It doesn't apply to the word processor integration plugins. Nobody has suggested that you use the Zotero client trunk XPI—in fact, you absolutely shouldn't.
  • michopop
    edited April 16, 2011
    OK, I got it... And I tried it:
    1. Yes, in some fields the field code was removed.
    2. No, it isn't faster at all.
    Now, because I want to continue with my work, and want to end the experiment - can you tell me how to restore zotero in its' previous condition? I don't see any "OpenOffice Integration Trunk XPI" among the plugins in Firefox or Openoffice to simply uninstall it.

    And Please write if you have any other Ideas how can I make it work faster... Thank you!
  • adamsmith
    un-install the Open Office Integration plugin that is currently installed - that's the trunk version. Then re-install the old one.
  • michopop
    edited April 18, 2011
    I tried it once more and compared the standard OpeOffice.org Integration 3.5a1 and the Trunk XPI:

    OpeOffice.org Integration 3.5a1: first citation 16 s, every next 12 s, edit cit. 12 s.
    Trunk XPI: first citation 12 s, every next 7 s, edit cit. 7 s.

    PS. I use the latest Firefox version, Openoffice 3.2.0. and Ubuntu 10.04.
  • fbennett
    edited April 18, 2011
    Just so you know that we do have this in mind, I spent some time yesterday working on a method of speeding up one of the bottlenecks in processing (disambiguation). The speed improvement was modest but significant in the processor test framework (about 30%), but might be much better in a large document with a large burden of disambiguation operations.

    Unfortunately, the experiment broke a number of disambiguation tests, so it's not useful in its current form. With a few more tweaks there might be potential for the approach I tried, however. I'll preserve the code from the experiment, and will look at it again when I have a bit of time to dwell on it.
  • michopop
    It's good to read this :). Just as information, on the contrary of what I experience in Ubuntu - a computer with a Windows XP and the same versions of openoffice, firefox and zotero needs max. 3 seconds for the first citation and less than a second for every next citation...
Sign In or Register to comment.