[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Beaver-devel] Segfault when closing document
From: |
Tobias Heinzen |
Subject: |
Re: [Beaver-devel] Segfault when closing document |
Date: |
Fri, 20 Jun 2008 17:47:21 +0200 |
User-agent: |
Thunderbird 2.0.0.14 (X11/20080505) |
Double 12 wrote:
The segfault also happens when doing Close (not just Close All).
I found out that it happens when you Close the document before all the
syntax highlighting is completed on the document. No wonder: when you
Close the document, it g_frees things that are still needed by
search_for_keyword_fastly to apply syntax highlighting.
I must test that out ^^ Perhaps the syhi also get's slowed down because
of the DEBUG_FCN (since it always has to print out something). For me
that was the case and I gained some speedup (which does not solve the
problem but still).
One option to solve this may be speeding up the syntax highlighting,
for example by removing some of the tons of Java keywords from
wordfile.h (not sure if that works, though).
I don't think so. As far as I understood the syntax highlighting is as
follows. It searches for a word in the text (lineary going through the
textbuffer until a space is found) then it is checked if the word must
be highlighted (this is done be looking it up in a hashtable. it could
be that the hashtable is to short and there are too many collission, so
the search get's worse). then this word is marked. after all words are
processed all markers get updated (this marker concept is builtin in the
GtkSourceView widget so no speeding up for that).
I think all get keywords get loaded at startup (which is really slow and
uses a lot of memory for perhaps uneeded stuff) for every language
(there's somewhere an array, forgott the name, which stores all
languagekeywords.) See my idea below, perhaps that will increase speed
up a bit.
Another option is
yes, the other option is? :-)
My idea is to just close the windows after the syhi is done.
By the way, Beaver uses 8 MB of memory on my system. That's a lot for
a *light-weight* editor, there are just three programs currently
running that use more memory.
This may be something for a later release, but I think we have to look
seriously at memory leaks and also prune the amount of features in
Beaver.
I understand that we want to have a full-featured editor, but maybe we
could remove things like: font selection, and the .bl-files function
to insert certain keywords via the Languages menu.
I completely agree with you. The .bl-files don't work for me at all
anyway (I think I'm still doing something wrong). What I thought of is
the following (which I thought of a really long time ago):
1) Why is there a single big wordfile anyway? Sure you've got everything
in one place, but this file is generated for every user and if there are
changes, then the user has to delete it's wordfile and let it newly
create. My idea was to create a xml-File for every language (the
XML-Parser part is easy since gtk has a parser builtin, that suffices
for that matter completely). These XML-Files are stored globaly
(somewhere in /usr/share/beaver). This has 3 advantages:
a) only those languages I need are loaded (why should I
preload Java when I never use it?)
b) changes and additions are made really easy. I never
understand fully the format of the wordfile it's just to complicated and
unmaintainable.
c) all users on the system immediatly got the new changes,
when they occur (though they have to restart beaver, but they don't need
to copy/generate the wordfile anymore). this also affects the size of
beaver.
In this xml files you also can add such thing like code completion
features (which is done now in .bl files)
2) The second idea (which like the first, I thought of it a long time
ago) was to provide a plugin system. This is really easy to do (just
about 20-50 lines of code for the plugin-loader). the advantage of this is:
a) stuff like colorpicker/font-selection are not affecting the
memory footprint and size of beaver directly as they can be activated
and removed as every user whiches (thus if you deactivate all plugins
you really should get a lightweight editor with just syntax highlighting)
b) it's just more maintainable by far
c) other developpers are encouraged to participate in the
beaver project as they don't have to look at all the code, they can just
provide a plugin which has an easy API.
The plugin system is cool, because you can add so much features so fast:
CVS, SVN, diff'ing you name it.