Statuses

Bluefish on the Raspberry Pi

In Bluefish, gtk+, Linux desktop, open source, Programming on January 1, 2013 by oli4444

After ordering in September, I finally received my Raspberry Pi a few weeks ago (the upside of the long time between order and delivery is that mine is the new revision with 512Mb RAM).

raspberrypi

I have no specific plans with the device other than playing a bit around with it. One of the things I obviously had to try was to run Bluefish as editor on the Pi. Installing all the build dependencies and compiling takes a few hours, but Bluefish was running as expected. Entirely true? No, some bits were slow, most notably the auto completion popup. So I dug into the code to find out why.

In the auto-completion popup, Bluefish has a “reference pane”. This shows some rerefence information about the item you are trying to auto-complete. For an HTML tag this might show the valid attributes, for a C function it might shown the arguments and the return codes etc. This is implemented with a hash-table and the “changed” signal on the GtkTreeSelection: if the selection changes, a lookup in the hash table is performed to see if there is reference information available. On the next key-press, bluefish re-calucalates the possible auto-completion candidates, and re-fills the GtkListStore that lies underneath the GtkTreeView. And this is where the problem was: before filling the list of items, Bluefish has to clear the old items. And the selection changed signal is called for each item that is removed from the GtkListStore, which in it’s turn does a hash table lookup and renders the reference information in the reference pane. Do that for 15000 items and you’ll have 100% cpu load for a second on the Raspberry Pi.

So what is improved now: first, the number of items in the auto-completion popup is limited to 500 items. Second a boolean is added that is set to TRUE whenever the popup is clearing or filling items. As long as that boolean is TRUE, the selection changed signal will do nothing at all.

2012-10-30-041644_1920x1200_scrot

The result: even on the Raspberry Pi, Bluefish auto-completion is again much faster than you can type, and every bit of sluggishness is gone. We’re close to the 2.2.4 release, and this fix will be part of 2.2.4!

About these ads

3 Responses to “Bluefish on the Raspberry Pi”

  1. Hey, testing performance problems with the Raspberry Pi is a good idea!

    > before filling the list of items, Bluefish has to clear the old items

    Between two populations of items, there are generally items in common. So clearing the model and refilling it completely implies some “row-deleted” and “row-inserted” signals that can be avoided. This is exactly how GtkSourceCompletion works, the items in common are kept in the model.

    I know that GtkSourceView is not used in Bluefish, but it should be quite easy to reuse the completion system with a simple GtkTextView.

    Currently the completion system in GSV is not perfect (bugs, problems in the API, not well documented, big Completion class not using the Model-View-Controller paradigm, …), but I’m working to fix these issues.

    I would be interested to know if the completion system of GSV would fit with Bluefish. And if not, why. The purpose is to improve the API so it is convenient to use for all text editors and IDEs. Currently, a big problem I think is the UI, which is a big window. A more compact and minimal view would be nice.

    • > Between two populations of items, there are generally items in common.

      True, so we’ll have to see if walking the model and the list to compare both populations is faster than just removing all and adding the new population. I have no idea what would be faster, but the code for remove all / add all is definitely much more simple.

      • I think that initially a simple GtkListStore was used in GSV, with a filter. Then a custom GtkTreeModel was implemented, and the commit message says that it improves significantly the performances.

        By working directly on the internal structure of the model, there are more chances that keeping the common items between two populations is more efficient.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: