GNOME's libspelling Turns To Threads For Much Faster Spell Checking

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    GNOME's libspelling Turns To Threads For Much Faster Spell Checking

    Phoronix: GNOME's libspelling Turns To Threads For Much Faster Spell Checking

    GNOME's libspelling library is seeing up to eight times faster spell checking performance thanks to threading and other optimizations...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • mxan
    Senior Member
    • Jun 2022
    • 289

    #2
    What was the point of writing yet another spelling library, again? Was Enchant not good enough?

    Comment

    • uid313
      Senior Member
      • Dec 2011
      • 6922

      #3
      I wish they would change the ugly red underline under misspelled words to something more discreet with thinner red dots. The red dots they have now are huge.

      Originally posted by mxan View Post
      What was the point of writing yet another spelling library, again? Was Enchant not good enough?
      Obviously Enchant wasn't fast enough. This new library uses threading and is highly optimized so it is much faster.

      Comment

      • spicfoo
        Senior Member
        • Nov 2023
        • 724

        #4
        Originally posted by uid313 View Post
        I wish they would change the ugly red underline under misspelled words to something more discreet with thinner red dots. The red dots they have now are huge..
        It is part of the widget that uses the library, not the library itself. Also Phoronix is absolutely the worst place to report bugs or feature requests. Go file a request in the appropriate issue tracker instead.

        Comment

        • varikonniemi
          Senior Member
          • Jan 2012
          • 1102

          #5
          Amazing that it took this long to get it off the main thread. Not that it had to be multithreaded from the start, but at least offload it to a single worker thread!

          Comment

          • whitor
            Junior Member
            • Jun 2020
            • 9

            #6
            Originally posted by mxan View Post
            What was the point of writing yet another spelling library, again? Was Enchant not good enough?
            This is not an alternative to enchant. It replaces gspell, which doesn't support GTK4. Both libraries use enchant under the hood.

            Comment

            • elduderino
              Phoronix Member
              • Dec 2020
              • 72

              #7
              Originally posted by varikonniemi View Post
              Amazing that it took this long to get it off the main thread. Not that it had to be multithreaded from the start, but at least offload it to a single worker thread!
              It really wasn't worth it at the time. Enchant is relatively fast for the vast majority of languages as the wrapped dictionaries tend to be mmap'able. Internally libspelling uses a B+Tree/PieceTable hybrid which outperforms pretty much everything out there for text range tracking (checked vs unchecked regions).

              What turned out to be the biggest slowdown was simply iterating through text in the GtkTextBuffer B-Tree. If you use the GtkTextIter API you have to create a PangoLayout for each line so you can get the PangoLogAttrs which describe each character and runs and written language breaking positions. That is a lot of extra work that just gets pushed out of the line cache immediately afterwards. Instead, just do the text analysis off thread.

              This wasn't obvious when creating it because the rest of the system was _so fast_ that unless you're opening 500MB log files with Text Editor nobody really seemed to notice.

              Additionally as it gets used with more dictionaries behind the scenes and more written languages the chances you hit a slow dictionary implementation increases.

              Comment

              • elduderino
                Phoronix Member
                • Dec 2020
                • 72

                #8
                Originally posted by whitor View Post
                This is not an alternative to enchant. It replaces gspell, which doesn't support GTK4. Both libraries use enchant under the hood.
                This is clearly the person who reads before commenting.

                Yes, libspelling is just the bridge between a GTK 4 application and enchant. But how you do that bridging can have a lot of impact.

                Comment

                • elduderino
                  Phoronix Member
                  • Dec 2020
                  • 72

                  #9
                  Originally posted by uid313 View Post
                  I wish they would change the ugly red underline under misspelled words to something more discreet with thinner red dots. The red dots they have now are huge.
                  That is caused by your font.

                  The size of the error underline is defined in Pango and is relative to the line underline height defined by your font (or something like that). I don't love it either, but that is GTK 4.18 territory.

                  Originally posted by uid313 View Post
                  Obviously Enchant wasn't fast enough. This new library uses threading and is highly optimized so it is much faster.
                  As others have pointed out, it uses enchant, so .... no?

                  Comment

                  • mb_q
                    Senior Member
                    • May 2017
                    • 231

                    #10
                    Originally posted by elduderino View Post

                    This is clearly the person who reads before commenting.

                    Yes, libspelling is just the bridge between a GTK 4 application and enchant. But how you do that bridging can have a lot of impact.
                    And enchant is glib wrapper dispatching to several actual spell-checkers, but most will use hunspell anyway. Apparently people will make arbitrary amount of bridges to avoid any actual programming. Yet Gnome is not the champion here; VSCode can connect through the DAP protocol over HTTP to LanguageTool server in Java to run the very same hunspell.

                    Comment

                    Working...
                    X