Zugg Software :: View topic

Wizard Joined: 14 Oct 2000 Posts: 1368

I noticed that when you press Get Latest From Library in the Library that after it downloads the files it takes about 1 minute before it is ready to display the contents.

There's only about 48 authors in the library, and about 100 scripts. I think it is way too slow saving that data to the database.

It is similar problem when downloading the MUD list. If you remove the muds.db file so that you get a clean mudlist with only avaible MUDs from TMC then after the download of the mudlist is complete it takes about 4 minutes for cMUD to process the mudlist. That is quite a lot for only 1800 MUDs. During that time cMUD is not responsive so you can't play while getting new list.

Wizard Joined: 14 Oct 2000 Posts: 1368

Also did a test with ctrl+q on cMUD and zMUD:
cMUD: about 4.2 seconds avg
zMUD: about 0.8 seconds avg

Posted: Tue May 06, 2008 8:36 pm

Sorry, but I am not seeing this speed issue at all. Can anyone else reproduce this?

For the MUDlist, CMUD is doing some processing on each MUD record to add some custom fields. But the package library is just using SQLite to create the database.

Did this change recently? Remember that for 2.24 I am only changing things that are *critical* or that changed since 2.23 because of a new problem. And this doesn't sound like either. You might also compare it to the speed in zMUD since it also used SQLite and should be doing about the same processing as CMUD for the MUD list (I know you can't test the package library in zMUD)

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Tue May 06, 2008 9:20 pm

I don't see that delay.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have remarked to myself that the Package Library is slow about processing its data, but it has been that way for a long time. It needs some optimization. I am going to guess the mud listing is the same, but I have never actually updated that. Neither really seems that pressing of an issue.

Posted: Tue May 06, 2008 10:33 pm

There is processing time while dealing with both of those updates but it never takes as long as what Rorso is experiencing and I know I did a full download and process of the mud list because I didn't install it when I installed CMUD and initially the mud list was entirely empty before doing get updates. It took less than a minute for my computer to process the full list.

Posted: Tue May 06, 2008 11:59 pm

I can probably speed it up in the future by using transactions. Right now each record is written to the database individually, and SQLite might be doing a lot of disk writing. If it's easy I'll change it, otherwise this will have to wait.

Edited: Btw, part of the problem is that it is updating the progress label on the screen for *every* MUD, which also slows it down a lot.

Edited: I added StartTransaction and Commit around the outside of both the MUDList and Package Library update routines. So this should speed it up a bit. I also reduced the number of update messages displayed for the MUD list (the package library already limited the update messages). Not sure how much it will help, but it's the only thing that's easy to do.

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Thu May 08, 2008 12:47 pm

Ok I timed the update of an empty to full mud list this time. My first impression is that it seems slower since not as many items get displayed in the dialog but that's just one of those mind trick things.

I can report it took exactly 1 minute to complete the whole process from pressing the button to downloading the list to processing the update.

My machine:
P4 3.8GHz
3GB RAM

EDIT: I did the PL just now and it took 10 seconds.

Wizard Joined: 14 Oct 2000 Posts: 1368

My computer is AMD Athlon 3200+ (2ghz), and 1 GB ram. Does anyone want to donate a faster computer? Mr. Green

Posted: Thu May 08, 2008 3:28 pm

I do actually have a better computer than that (4400+, 2gb ram, 7900gt that probably doesn't work, no disc drives) sitting around, but I think my parents have first dibs.

Posted: Thu May 08, 2008 6:41 pm

Rorso, sorry it's still slow for you, but there isn't much I can do about it. Databases just are not optimized for creating new records. In the future maybe I can find a way to speed it up by changing how/when the indexes are created (if that is what is causing the slowdown). But literally, all I am doing is this: