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

Tue Mar 31 17:05:22 UTC 2009

Hi, just a small 5 cent idea on scripting performances. Maybe this is really
stupid, just brainstorming.....
If I understood correctly state must be prevented for some critical scripts
(probably just 3-4 in a sim), but if the overload of doing it for every
other 4000 pieces of scripts just switching colors or animating a texture
would be too much.
What about some comments allowing us to disable such "features" and make
lighter scripts run faster?

Some markers  like
// @TRANSIENT (no need to store on disk the state)
// @NOLINES (no need to store lines: we already debugged the 5 lines of it
and are satisfied :)
// @some other exclusion
or similar to give the XEngine some hints on how to deal with scripts and
produce welcome optimizations?

(I remember that something similar was already done to choose the running
engine in the past and probably still there).

I'm also very curious to understand why sims are currently using 200% of the
cpu on the first minutes (sometimes even 6-10 minutes).. Is that all related
to scripts? or is it the creation of all prims? Or is the new jpg cache
loading all the textures?

On Thu, Mar 26, 2009 at 17:10, Melanie <melanie at t-data.com> wrote:

> 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
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090331/c8a7259b/attachment-0001.html>