Hi, just a small 5 cent idea on scripting performances. Maybe this is really stupid, just brainstorming.....<div><br><div>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.</div>
<div>What about some comments allowing us to disable such "features" and make lighter scripts run faster?</div><div><br></div><div>Some markers  like</div><div>// @TRANSIENT (no need to store on disk the state)</div>
<div>// @NOLINES (no need to store lines: we already debugged the 5 lines of it and are satisfied :)</div><div>// @some other exclusion </div><div>or similar to give the XEngine some hints on how to deal with scripts and produce welcome optimizations?</div>
<div><br></div><div>(I remember that something similar was already done to choose the running engine in the past and probably still there).</div><div><br></div><div>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?</div>
<div><br><br><div class="gmail_quote">On Thu, Mar 26, 2009 at 17:10, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have made some changes that alleviate some of the issues you have<br>
highlighted without defeating the purpose of the line maps and state<br>
files.<br>
<br>
Specifically, scripts are no longer compiled just to generate the<br>
map. Rather, the map is stored in a separate text file which is read<br>
  on sim startup for already present assemblies.<br>
<br>
Also, state is not saved if it hasn't changed from the stored<br>
version. This doesn't help the performance hit that is caused by the<br>
initial writing of the state file, but that can't be helped, that<br>
action is important for real-world use of the scripting system.<br>
<br>
A possible next step would be to move state storage to a faster<br>
storage medium.<br>
<div><div></div><div class="h5"><br>
Melanie<br>
<br>
Lake, Dan wrote:<br>
> 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.<br>

><br>
> ~Dan<br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Melanie<br>

> Sent: Thursday, March 26, 2009 6:43 AM<br>
> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: Re: [Opensim-dev] Updated: OpenSim profiling on ScienceSim wiki<br>
><br>
> Hi,<br>
><br>
> i propose to move line map caching into the base64/XML<br>
> representation of the script that is stored in the filesystem for<br>
> script crossings. Like the binary, that file is created only during<br>
> the compile and the script instance code could read it only when the<br>
> line map is needed (to display a runtime error, which is rare).<br>
><br>
> Script state files are stored because sims do crash and scripts like<br>
> rent boxes and networked vendors can't be allowed to lose state in a<br>
> sim crash. The file system was the first chance opportunity to put<br>
> these files, but script counts were maxing out at about 50 when i<br>
> coded that.<br>
><br>
> Would a database really be that much faster? If so, I have no issues<br>
> with that stuff being moved to the database. I simply wanted to<br>
> avoid storing yet more blobs.<br>
><br>
> Melanie<br>
><br>
> Lake, Dan wrote:<br>
>> I posted some new OpenSim profiling results on the ScienceSim wiki at <a href="http://sciencesim.com/wiki/doku.php/opensim/performance_profiling" target="_blank">http://sciencesim.com/wiki/doku.php/opensim/performance_profiling</a>.<br>

>><br>
>> 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.<br>

>><br>
>> 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.<br>
>><br>
>> 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.<br>

>><br>
>> There are still a number of performance limitations with managing lists of updates, timers, and scene object inventories.<br>
>><br>
>> Your comments or feedback are appreciated.<br>
>><br>
>> Dan lake<br>
>> Network Software Engineer<br>
>> Network Technology Lab<br>
>> Corporate Technology Group<br>
>> 503.712.8318<br>
>> <a href="mailto:dan.lake@intel.com">dan.lake@intel.com</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
>><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div></div>