Long long delay after unused

[quicknir]

My rtags server is generally running in the background doing it's thing. If I don't use it for a while, then the first time I try to do go to definition, it takes longer. It would be okay for it to be moderately longer, but it often takes around 10 seconds. After that it goes back to it's typical half second or so. Is there any way this delay can be reduced or eliminated? Maybe some kind of option that it's ok for rtags to be more aggressive about consuming resources and to not fall asleep (if that's what's happening, in some sense).

[Andersbakken]

My guess is that it's fileio actually. RTags' database is mostly mmap'ed files. We could have an option poll every once in a while but I suppose one could do that in a cronjob as well. Anders

[quicknir]

@Andersbakken I think at some point it would be good if you added an option; rtags already needs to do quite a lot of work in the background so doing this in the background every 10 seconds or so, in exchange for instant wakeup, is probably a good tradeoff for most people.

The issue with a cronjob (I'm not very familiar with cron, so maybe this is ignorance) is that if I turn off the rtags server, it keeps doing its thing unless I explicitly shut it down, so you have a bunch of pointless commands being issued that all end in errors. A second issue is that in some cases messing around with the crontab is a bit dicey. E.g. I work on a shared server with a few other people, I'm not sure if other people would love me adding a crontab entry for my IDE when it's largely reserved for much more important things like nightly jobs that we depend on in various ways.

[Andersbakken]

Hi I added a switch that enables you to do this. If you run rdm like this: rdm --poll-timer 5 It will open and mmap every file for the current project in the database every 5 seconds. Note that for bigger projects this could be rather heavy if the timer is too frequent. rtags will also be unresponsive during validation so for big databases this option may not be ideal. I suppose we could introduce threads if there turns out to be a performance problem. Let me know if it helps. Anders

…

On Mon, Dec 12, 2016 at 7:43 AM, quicknir ***@***.***> wrote: @Andersbakken <https://github.com/Andersbakken> I think at some point it would be good if you added an option; rtags already needs to do quite a lot of work in the background so doing this in the background every 10 seconds or so, in exchange for instant wakeup, is probably a good tradeoff for most people. The issue with a cronjob (I'm not very familiar with cron, so maybe this is ignorance) is that if I turn off the rtags server, it keeps doing its thing unless I explicitly shut it down, so you have a bunch of pointless commands being issued that all end in errors. A second issue is that in some cases messing around with the crontab is a bit dicey. E.g. I work on a shared server with a few other people, I'm not sure if other people would love me adding a crontab entry for my IDE when it's largely reserved for much more important things like nightly jobs that we depend on in various ways. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#867 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdSgOC_PCkT6gMvw5fk5yhNWCJROFXks5rHWuYgaJpZM4LG_f5> .

[quicknir]

@Andersbakken It definitely does seem to be better. What I see now is that I don't get anywhere near as long of a delay up front. But the perf does seem a bit more sluggish compared to how it was before, when things had already gotten "warm" as it were. I'll try changing the poll timer to 10 seconds, see how things go, and also I'll try turning the poll timer off and making sure it's not my imagination. Thanks!