I have made some changes that alleviate some of the issues you have highlighted without defeating the purpose of the line maps and state files.
Specifically, scripts are no longer compiled just to generate the map. Rather, the map is stored in a separate text file which is read on sim startup for already present assemblies. Also, state is not saved if it hasn't changed from the stored version. This doesn't help the performance hit that is caused by the initial writing of the state file, but that can't be helped, that action is important for real-world use of the scripting system. A possible next step would be to move state storage to a faster storage medium. Melanie Lake, Dan wrote: > I don't honestly know the speed of something like a MySQL query compared to > creating a text file. I have to believe that an SQL query to store a 500 byte > blob is faster than serializing to a an XML string and creating a new file to > write the string into. The current code follows that up with another > filesystem check to make sure the file was really created after the > try/catch. This is a 2X increase in rez performance compared with a 5X > increase for the convert/compile step. > > ~Dan > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Melanie > Sent: Thursday, March 26, 2009 6:43 AM > To: [email protected] > Subject: Re: [Opensim-dev] Updated: OpenSim profiling on ScienceSim wiki > > Hi, > > i propose to move line map caching into the base64/XML > representation of the script that is stored in the filesystem for > script crossings. Like the binary, that file is created only during > the compile and the script instance code could read it only when the > line map is needed (to display a runtime error, which is rare). > > Script state files are stored because sims do crash and scripts like > rent boxes and networked vendors can't be allowed to lose state in a > sim crash. The file system was the first chance opportunity to put > these files, but script counts were maxing out at about 50 when i > coded that. > > Would a database really be that much faster? If so, I have no issues > with that stuff being moved to the database. I simply wanted to > avoid storing yet more blobs. > > Melanie > > Lake, Dan wrote: >> I posted some new OpenSim profiling results on the ScienceSim wiki at >> http://sciencesim.com/wiki/doku.php/opensim/performance_profiling. >> >> In my previous post, I used a workload which rezzed 2,000 objects as quickly >> as possible. Each object a script and timer to rotate and change color every >> 1-5 seconds. After those optimizations to r8536, it took about 1.5 minutes >> to rez 2,000 objects with an 80% reduction in stead state CPU utilization. >> >> Today's update describes the changes which enable the same scene to rez >> 10,000 scripted objects in the same 1.5 minutes (5X rez rate) and rez up to >> 40,000 objects in 8 minutes. >> >> I also describe a change to script state persistence that may enable up to >> 10,000 objects to be rezzed per minute, and a much higher scene maximum with >> respect to state. I have tested that idea out and was able to rez 50,000 >> scripted objects in under 5 minutes. The sim was between 25-30 FPS and only >> 3 of 4 processor cores were utilized. >> >> There are still a number of performance limitations with managing lists of >> updates, timers, and scene object inventories. >> >> Your comments or feedback are appreciated. >> >> Dan lake >> Network Software Engineer >> Network Technology Lab >> Corporate Technology Group >> 503.712.8318 >> [email protected] >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
