zim-wiki team mailing list archive

[hansbkk@xxxxxxxxx]

Just created a new notebook and WOW is that nice and snappy.

Confirmed it wasn't the fact it was on an encfs filesystem, nor that
dropbox is sync'ing while things are unencrypted

I guess I just let my "main" tree get too large?

Are there any guidelines as to number of nodes, size of files where
things start to bog down like that?

Really has been getting pretty much unusable, sometimes over a minute
of "greying out" to move to a different node, sometimes another cycle
to get the cursor back ready to insert new text into the file. . .

I guess I'll just need to regularly parse out from an old to a new notebook.

Or maybe I'll try having separate "sub-notebooks" at the head of
particularly large sub-topic trees.

I'm also starting to research using Org-mode in Emacs - anyone have
suggestions of good package combos to give Zim-like functionality
there?


On Tue, Apr 29, 2014 at 4:18 PM, Jaap Karssenberg
<jaap.karssenberg@xxxxxxxxx> wrote:
>
> On Thu, Apr 17, 2014 at 11:37 PM, <hansbkk@xxxxxxxxx> wrote:
>>
>> OK, didn't reboot but shutdown Zim, killed Python processes still
>> running, then launched from console
>> zim --debug
>>
>> Here's the output: http://gist.github.com/anonymous/11012787
>>
>> Note my .config under ~/ as well as the Zim/python installs are on a
>> normal ext3 filesystem, but looking at this reminded me my data folder
>> is encrypted with encfs and (once decrypted) sync'd via Dropbox.
>>
>> I have tested after killing the Dropbox process, no change.
>>
>> Next step - if you guys don't see anything in the gist - will be to
>> move the data folder and test again.
>>
>> If that is the problem, then suggestions for an alternative
>> user-transparent encryption solution that doesn't slow things down
>> would be greatly appreciated.
>>
>> PS thanks so much to the developer(s) and other contributors for this
>> excellent software, finally weaned myself away from Evernote after
>> nearly a decade's addiction.
>
>
> The debug log looks entirely normal, no hints to be found there.
>
> One thing that might be happening is that the index update that is running
> after starting zim is having to do a lot of maintenance. When you start zim,
> wait a bit until you see a debug message that the index update is done
> before trying other stuff. Or you can force an index update by running "zim
> --index" after closing the gui.
>
> THis stuff of course depends on the number of pages, lenght of pages etc.
> But unless those numbers are really ridiculously large it should resolve
> itself.
>
> If that does not help I would indeed think about the filesystem speed, or
> other things that could interact.
>
> Regards,
>
> Jaap
>

On Tue, Apr 29, 2014 at 4:18 PM, Jaap Karssenberg
<jaap.karssenberg@xxxxxxxxx> wrote:
>
> On Thu, Apr 17, 2014 at 11:37 PM, <hansbkk@xxxxxxxxx> wrote:
>>
>> OK, didn't reboot but shutdown Zim, killed Python processes still
>> running, then launched from console
>> zim --debug
>>
>> Here's the output: http://gist.github.com/anonymous/11012787
>>
>> Note my .config under ~/ as well as the Zim/python installs are on a
>> normal ext3 filesystem, but looking at this reminded me my data folder
>> is encrypted with encfs and (once decrypted) sync'd via Dropbox.
>>
>> I have tested after killing the Dropbox process, no change.
>>
>> Next step - if you guys don't see anything in the gist - will be to
>> move the data folder and test again.
>>
>> If that is the problem, then suggestions for an alternative
>> user-transparent encryption solution that doesn't slow things down
>> would be greatly appreciated.
>>
>> PS thanks so much to the developer(s) and other contributors for this
>> excellent software, finally weaned myself away from Evernote after
>> nearly a decade's addiction.
>
>
> The debug log looks entirely normal, no hints to be found there.
>
> One thing that might be happening is that the index update that is running
> after starting zim is having to do a lot of maintenance. When you start zim,
> wait a bit until you see a debug message that the index update is done
> before trying other stuff. Or you can force an index update by running "zim
> --index" after closing the gui.
>
> THis stuff of course depends on the number of pages, lenght of pages etc.
> But unless those numbers are really ridiculously large it should resolve
> itself.
>
> If that does not help I would indeed think about the filesystem speed, or
> other things that could interact.
>
> Regards,
>
> Jaap
>