1. 23 Feb, 2021 1 commit
  2. 15 Feb, 2021 5 commits
  3. 14 Feb, 2021 4 commits
  4. 07 Feb, 2021 1 commit
    • Carlos Garnacho's avatar
      tracker: Drop Tracker code · e9215d33
      Carlos Garnacho authored
      The story of saved contacts in Tracker is a convoluted one,
      and this code is mostly an artifact. 65 Million years ago, when
      Nokia dominated the world, Maemo/meego relied on Tracker and had
      specialized contact apps that used it as a storage.
      
      After Elop hit the Earth, saved contacts barely survived the
      event, mostly feeding off a small Evolution plugin. But that
      was not meant to last long, the evolution plugin went extinct,
      taking all traces of saved contacts with it. Just the ontology
      remained, a hollow shell that yes, could be able to hold a
      contact, would they still exist.
      
      Modern times arrived, and with them the interest on archeology,
      thus this fossilized piece of code is found and taken to the
      museum where it belongs.
      
      Should Tracker-using contacts ever exist again, the way to
      communicate with them would be radically different, let this code
      be a testimony of how it won't be done.
      
      Fixes: #126
      e9215d33
  5. 31 Dec, 2020 1 commit
  6. 05 Dec, 2020 3 commits
  7. 28 Nov, 2020 5 commits
    • Niels De Graef's avatar
      edsf: Avoid Gee.LinkedList in copy_contacts(_ids) · 17923978
      Niels De Graef authored
      When we receive a signal that adds/removes/changes contacts, we get a
      list of the affectefd contacts (or their ID's). Since we process them at
      a separate point in time in the main loop, we have to make a copy to
      make sure that they're still around when being processed.
      
      The current way we do this, is by creating a `Gee.LinkedList`, and
      appending each entry at the end (note that appending an item is an O(1)
      operation in `Gee.LinkedList` since it keeps track of its last element).
      However, there's some problems with this approach:
      
      * Each time an element is added into the list, a little helper object (a
        `Node`) is allocated. This is yet again just another unnecessary
        allocation that we wish to avoid.
      * Iterating over any `Gee.Collection` gives you an owned reference to
        each element, meaning we do unnecessary copies or reference count
        fiddling.
      
      Most of these issues can be solved quite elegantly by using
      `GLib.GenericArray` (ie. `GPtrArray`), which will keep track of the
      owned references, but won't try to do anything fancy with it.
      17923978
    • Niels De Graef's avatar
      edsf: Avoid E.VCardAttribute.get_value() · 25d83d3e
      Niels De Graef authored
      This will always copy the value, even when we don't need it. Use
      `get_values()` instead, and return the first element.
      25d83d3e
    • Niels De Graef's avatar
      edsf: Persona: Add get_string_property() · 08713ade
      Niels De Graef authored
      By default, getting a property will duplicate the value. However, for
      string fields, we can do better, since `E.Contact` then provides a
      `get_const()` methods. Especially given the amount of string properties
      that are always loaded, this makes a big difference for large address
      books.
      08713ade
    • Niels De Graef's avatar
      Cut down on the amount of owned variables · 64ab5aa9
      Niels De Graef authored
      In a lot of places in Folks, we unnecessarily create a lot of owned
      variables. Although the performance impact of a string copy or a
      refcount increment is normally completely not a concern, we also do this
      in a lot of hot code paths (e.g., for each contact that is loaded). This
      in turn mostly impacts larger address books.
      64ab5aa9
    • Niels De Graef's avatar
      persona: Don't use string.replace · 2a0ac05e
      Niels De Graef authored
      Although it's supposedly part of `glib-2.0.vapi`, `string.replace` is
      _not_ a function implemented by GLib. Worse, what it does is to create
      and compile a `GRegex`, which then gets used to do the substitution.
      
      Since we call `Persona.build_uid()` for each persona, and then even 3
      times in a row, we create an amount of unnecessary temporary
      allocations that linearly increases with the amount of contacts.
      
      To mitigate this, use a `GString` (aka `GLib.StringBuilder`) and try to
      allocate the right amount from the start.
      2a0ac05e
  8. 24 Aug, 2020 1 commit
  9. 23 Aug, 2020 1 commit
  10. 18 Jun, 2020 1 commit
  11. 07 Jun, 2020 9 commits
  12. 27 Apr, 2020 1 commit
  13. 11 Mar, 2020 2 commits
  14. 10 Mar, 2020 1 commit
  15. 22 Feb, 2020 1 commit
  16. 04 Feb, 2020 3 commits