Mudlet locking/freezing/lagging

Daslin

Alright. I've torn mudlet mapper out over and over and over and over now. And yet, I still lock when someone calls a location on pt. Well, we have ANOTHER fun one here. After popping over to Eleusis, Iakimen lands. Shields. I swap targets. hit my dsl alias ONCE. Mudlet doesn't move. I go well shit, will I live? When it unfreezes, BOTH groups have arrived and most everyone is dead. So I type "Embrace death" hit enter, and scroll up to grab all the text to show mr @Vadimuses aaaand this happened. http://snag.gy/jcHq7.jpg

Vadimuses

methinks you need to wipe the map.

Kayeil

My Mudlet lags really bad and sometimes freezes when I have someone following me. This has only been an issue since I got SVO. 

Strata

Kayeil said:

My Mudlet lags really bad and sometimes freezes when I have someone following me. This has only been an issue since I got SVO. 

I have the same problem even on my fastest machine which is a core i7. It's definitely mapper and namedb slowing things down. Not having alertness up when people are following definitely helps.

Rangor

try npp and/OR ndb delete all.

Tharvis

or just disable NDB altogether, fixed so much lag for me

Severina

For those savvy enough, it's also marginally helpful to vacuum the backend sqlite db namedb stores its data in after deleting swaths of folks. It'd be nice if @Vadimuses could have ndb do this automatically, though perhaps it does already and I just can't find where.

Nemutaur

I just put these two lines of code in an alias and run it once a week or so. It will delete anyone from ndb who is unranked or below xp rank 2000. Both of which I don't care about.

db:delete(ndb.db.people, db:gte(ndb.db.people.xp_rank, 2000))
db:delete(ndb.db.people, db:eq(ndb.db.people.xp_rank, -2))

Strata

Severina said:

For those savvy enough, it's also marginally helpful to vacuum the backend sqlite db namedb stores its data in after deleting swaths of folks. It'd be nice if @Vadimuses could have ndb do this automatically, though perhaps it does already and I just can't find where.

In theory, your OS would likely have the sqlite db in a buffer cache because it's being hit constantly, so disk latencies are probably not a major contributing factor to the lag. Sqlite makes sense from an embedded standpoint (requires no running services). Writing to sqlite (when new names are mined via ndb) is going to be slow because afaik sqlite only allows one write operation at a time. Reads should be quite fast, however.

I think it's more to do with the sheer amount of temp triggers and string subbing going on to colorize the names. That's a lot of code running (possibly 1000's of lines) for every line of text received from the mud. And that's just ndb. Then there's the rest of the system.

Nemutaur has a good idea. It would be cool if @Vadimuses added some configuration options to let us specify criteria like XP rank and such that ndb considers pertinent enough to store in the database. This would ideally keep the database smaller and thus faster.

Vadimuses

There could be two things at play here - either the peopletracker plotting people on the map or ndb doing person colour lookups for the alertness message. Both of these things have been combed over many times for optimization, not much more improvemenet available there I don't think - besides having less data.

You can disable the people plotting on map if you don't use it by doing vconfig peopletracker off. See if that helps it. You can test the alertness colour theory by finding the Mudlet Mapper prompt trigger and changing the if ndb then line to if false then to disable it.

Mudlet already calls vacuum on a database every time you open it up with db:create (see conn:execute("VACUUM") in db:_migrate), so that shouldn't be it.

Less people in the database is of course going to work but that doesn't address the root of the problem, which I would like to be determined with concrete evidence. It's much better to surely know the problem and fix it than keep poking it with workarounds. An option to prune the DB if you don't want to know all the names certainly would be fine however.

Writing to the DB is slower, but NDB already disables disk flushing by setting syncronous to be off - you wouldn't be able to use Mudlet while it is checking names if your connection was relatively fast enough with this option on.

Name highlighting is actually super fast and I don't think is the issue - qw with ndb on takes 80ms with my entire system, with it off it is 75ms. 5ms for 112 names at once is quite OK, it works out to 0.000045s or 0.044ms.

Just some background info there to add to the mix.

Kayeil

I did vconfig peopletracker off and it's WAY better and faster now. Thank you so much! 

Rangor

Found a new symptom that causes my mudlet to break. Basically the main display starts lagging, then it freezes. The channel window keeps going even though the main window is frozen. Then after a bit mudlet breaks. Obvious memory leak, but dunno what's causing it!

Jules

Nemutaur said:

I just put these two lines of code in an alias and run it once a week or so. It will delete anyone from ndb who is unranked or below xp rank 2000. Both of which I don't care about.

db:delete(ndb.db.people, db:gte(ndb.db.people.xp_rank, 2000))
db:delete(ndb.db.people, db:eq(ndb.db.people.xp_rank, -2))

It says that Nemutaur put this in "an alias".  Did he maybe actually insert it in some appropriate place in one of the existing aliases, or even in the associated scripts?  It's not working as an alias for me.  

Jules

It looks like maybe he put it in the ndb update all alias right under where it says local alldata = db:fetch(ndb.db.people), or something like that.

Jules

This seems to have nicely pared my db down to 1420 names, which all seem to be active people who are above rank 2000, but everytime the check actually starts it says I have 1402 two names (and then when I run it again, it warns me I have 1420 names.  Is it running who in the background everytime it starts and there are just 18 people on right now who are low ranked?