beaver-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Beaver-devel] Segfault when closing document


From: Double 12
Subject: Re: [Beaver-devel] Segfault when closing document
Date: Fri, 20 Jun 2008 18:07:19 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080505)

Yes, the syntax highlighting gets significantly slowed down by the printing of the DEBUG_FCN messages, but without DEBUG_FCN, applying the syntax highlighting on long documents still takes a long time.

Hehe, I forgot to mention the second option. The first option was to speed up syntax highlighting. The second option is to set the Close-button as non-sensitive (not clickable) while the highlighting is still in progress.

>> My idea is to just close the windows after the syhi is done.
What do you mean exactly?

Your XML-file and plugin ideas are great :) If we implement these things (together with upgrading to GtkUiManager), we could call our next version 0.4.0. But I think a basic set of commonly used languages for syntax highlighting (C/C++, Bash, Python) can be automatically loaded.

Double 12


Tobias Heinzen schreef:
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.


_______________________________________________
Beaver-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/beaver-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]