1. 20 Mar, 2019 1 kayıt (commit)
    • Miklos Vajna's avatar
      sw: make ODT export of paragraph auto-styles deterministic · eb128a7d
      Miklos Vajna yazdı
      If a complex enough document is loaded into Writer and saved as ODT,
      then the content.xml's automatic paragraph styles (P<num>) are
      re-ordered on each save, which leads to unnecessary noise.
      
      The actual random order is created during import by the time we convert
      direct formatting (e.g. from HTML import) to autostyles, as
      StylePoolImpl::maRoot stores autostyles in a map that orders autostyle
      parents based on their pointer address.
      
      This has benefits like automatic ordering of item sets and fast
      comparison, so don't change that, but extend the svl API to also track
      the name of those parents.
      
      This way by the time StylePool::createIterator() would iterate over
      those autostyles, it can order the parents by their name, so two
      import->export runs will result in the same autostyle ordering.
      
      (This appears to be the only indeterminism in content.xml for a test
      HTML input, while meta.xml and settings.xml still changes all the time.)
      
      Change-Id: I1cfcae2c664a5c5c3dee48be733046979c1593ed
      Reviewed-on: https://gerrit.libreoffice.org/69469Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.com>
      Tested-by: Jenkins
      eb128a7d
  2. 09 Haz, 2016 1 kayıt (commit)
  3. 17 Haz, 2014 1 kayıt (commit)
    • Michael Meeks's avatar
      fdo#38513 - Accelerate non-poolable item add / remove. · 1ca7ac12
      Michael Meeks yazdı
      For large documents we create and destroy a large number of non-poolable
      SfxPoolItems, which get inserted into and removed from a vector.
      Unfortunately the performance of this (depending on pattern) is O(N) and
      this insert/remove/extend pattern can happen per text span we insert.
      This patch makes this O(const) via a hash. This gives a 5x speedup for
      the above bug; 176s to 34s or so, and moves the remaining performance
      issues elsewhere.
      
      Unfortunately, we have to retain the ordered array to keep the binary
      file format code (used for editeng cut-and-paste) in place, so have to
      keep both a hash, and an array, and a list around for free slots. cf.
      fdo#79851 where there is a start at removing that.
      
      This wastes space; but not that much - for a large open document
      collection we have O(100's) of SfxItemPools, and O(1000's) of
      SfxPoolItemArray_Impls; having fixed fdo#79851 we can consolidate this.
      
      Add skeletal unit test; translate several German comments; remove
      un-necessary include.
      
      Change-Id: Ie0de32b1a29217560c5591c71a6cd4e26d39a531
      1ca7ac12
  4. 11 Mar, 2014 1 kayıt (commit)