[Opensim-dev] Updated: OpenSim profiling on ScienceSim wiki

[Melanie]

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: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Thursday, March 26, 2009 6:43 AM
> To: opensim-dev at lists.berlios.de
> 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
>> dan.lake at intel.com
>>  
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>