Any lag due to database size?

that's basically it - can the size of the database have an impact on the performance of the game - say a lot of items or weapons/armor?

If you have a lot of switches defined, or variables, or use self switches a lot, can it slow anything down (maybe checking what event tabs are active)?

I don't think database sze matters. Having a lot of events can though, yeah.

I know events can, but what about on maps where there aren't many events, and the lag isn't coming from the events?

Would the fact that, say, 8 events on a map use switches or self switches, but I might have a thousand switches in the complete game, cause lag?  Are the arrays/tables used by the database going to slow things down if they are quite large?  Or is lookup speed not an issue?

I know events can, but what about on maps where there aren't many events, and the lag isn't coming from the events?

Would the fact that, say, 8 events on a map use switches or self switches, but I might have a thousand switches in the complete game, cause lag?  Are the arrays/tables used by the database going to slow things down if they are quite large?  Or is lookup speed not an issue?

It does increase with the size of the array, but I don't imagine it would be noticable by itself. Have you tested it?

Testers are reporting lagging on maps that have few events.  No parallel processes or autorun events are active. 

I can't duplicate the issue, but my pc is probably a little more souped-up than theirs.  I don't notice any lag.  But I believe they're seeing it - I wish I could reproduce it.

Do they report it as soon as they enter the map? Or do they do something and then it starts?

I believe it's all the time when in those maps.  They don't do anything and suddenly notice that it's lagging.

I HAVE noticed that when I enter dungeon maps, the map takes a much longer time than usual to load - game freezes and for about 3 seconds the map is dark, with what appears to be the old and new map overlaid together.  But that's a different issue to what they're having.

Well... You can't seem to reproduce the lag yourself, otherwise I'd tell you to try and troubleshoot by deleting one event at a time and running the map. If the testers have an unencrypted game, you could get them to give it a try. I think Shadow had an issue with lag at some point that anti-lag scripts didn't fix and he discovered it was an issue inside of some random event that wasn't even running parallel or auto.

This happens on multiple maps though.

I'm waiting for further feedback, but my next step is probably going to be loading it up on my lower-powered laptop and see if I can reproduce it.

Thanks

hmm... how large are your tilesets?

not big.  The cavern ones aren't as big as the cavern tilesets in the RTP.  Actually most of the tilesets are smaller than the RTP tilesets.

However, for future reference, does that make a difference, and why?

Why? I don't really know. But it does.

Yeah, large tilesets and large maps can cause lag, but if they aren't any larger than the RTP then that definitely isn't the problem. Why they cause lag has to do with the way tileset data is called in RMXP.

Anyway, I'm hardly an expert when it comes to reducing lag. One thing to check might be the number of pages in an event. If there are many many, then each page's conditions have to be checked until one matches, so that might eb a problem. Conditionals are generally pretty fast though.

The only other thing I can suggest is getting an Anti-Lag script. Zeriab's in the database is very good.

Also, what are these people's computers like. The minimum requirements for RMXP are:

    * Microsoft® Windows® 98/98SE/Me/XP/2000
    * PC with 800MHz Intel® Pentium® III equivalent or higher processor
    * At least 128 MB of system RAM
    * 1024x768 or better video resolution in High Color mode
    * DirectSound-compatible sound card
    * At least 100 MB of available hard disk space

If they don't meet that, then it'll be hard to solve their lag problems.

Thanks MA. 

We've already got an anti-lag script, and I don't think the number of events is the issue.  We're seeing lag on maps with few events, but not as much lag on maps with more events.

You might be onto something with the number of event tabs - I think about 10 is the highest we have, but it's unusual for the events to have more than 4 or 5.

You do give me a couple of other things to think about though...

I'll also check the stats of the players.  I'm pretty sure most of them meet the requirements, but I do have that info available so should look it all up.

Thanks

The size in itself is not significant. You can easily make 999 of all the various items. The problem is their application.
If you have 5k switches, but only use a couple every frame then there is no problem at all.
Having 50k switches and having at most 10 switch changes per frame lags less than having 20 switches with 100 switch changes per frame. The same applies with variables.
If we look common events then at each frame the properties of each common event is checked. This effectively means that as you put more common events in the game even with no trigger the update settings of more common events have to be checked every turn.

The time of looking up a single entry does not change. Or at least not in any noticeable way with the sizes of the arrays you'd be dealing with. The shop processing runs through the items, weapons and armors when you open it.
The difference between the default settings and having 999 of each may be noticeable, maybe not. The size of the database will not cause serious lag.
As for the pages of events it should take longer as you use more pages, but you are limited to 99 pages and page switches only happen fairly rarely and even more rarely at the same time. Note the higher the page number in use the less power it takes to choose the page.

A much better approach than I have done here would be to test out the effects of increase the database size. Do it with extreme values and see what parts slow down when certain parts of the database are big. (You probably need a Database breaker script for this)

*hugs*
 - Zeriab

Thanks Zeriab.

I was thinking the size wouldn't really matter for most of those.  Interesting comment about common events - I hadn't thought about that.  Definitely worth keeping in mind.

It definitely is since they are checked every frame.
It's not as interesting if you are using my anti lag script since only scripts on Autorun or Parallel trigger needs to be considered unless the triggers can change at runtime. (It's not default and I have never heard or seen a script which changes the triggers of common events)

*hugs*
 - Zeriab