I`d like to see the facts based on that assumption. I`ve worked with NHibernate in web solutions for years and there hasn`t been any lack of performance. I had a one year pause with Hibernate and it seems during it there has been great development, nhibernate own cache etc. <br>
<br>If we assume that NHibernate is currently slower there is sure a plenty of ways to get it faster. Indexing, caching, bulk fetches to mention few.<br><br>Best,<br><br> - Antti<br><br><div class="gmail_quote">2009/2/18 Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">NHibernate has, in tests, been significantly slower than native<br>
implementations.<br>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="Wj3C7c"><br>
Antti Kokko wrote:<br>
> Trying to catch up but anyway what I think in general is that the whole<br>
> database schema is not the best in terms of coherence, associations etc. For<br>
> me it seems that at first came all functionality and them came the database<br>
> solutions. The structure feels is "broken" but I understand it because of<br>
> grid mode etc.<br>
><br>
> What I`d like to see is simply one db solution which covers mysql, mssql and<br>
> sqlite and that is most propably NHibernate. Why do all the updates to all<br>
> interface implementing classes instead of doing it only in one place. I<br>
> think this could save some serious time.<br>
><br>
> However I try to get to the asset discussion:<br>
><br>
> First of all I really like the way of Cable Beach and truly hope this all is<br>
> going to distributed asset system. One of the biggest issues is cache,<br>
> external cache etc. If we have e.q. publisher who wants to update an object<br>
> in Cable Beach which is already used in sim1 and sim2, how we send the<br>
> update to all caches? How I have understood it the current system is a kind<br>
> of trade-off and actually new object is created instead of updating the<br>
> existing one. On the database side I`d definitely like to see not a new<br>
> object but an update. What I`ve heard the cache issues are long discussed<br>
> and not easy to resolve and we definitely need a further discussion about<br>
> along with Cable Beach or any distributed asset system. After all why I<br>
> couldn`t have an apache web server somewhere where my asset, avatar, avatar<br>
> appearance are.<br>
><br>
> Having several asset storages distributed all over the web we need an UUID<br>
> for the asset but we are going to need of course an URL as key too. That is<br>
> definitely one issue.<br>
><br>
> Best,<br>
><br>
> - Antti<br>
><br>
> 2009/2/17 Charles Krinke <<a href="mailto:cfk@pacbell.net">cfk@pacbell.net</a>><br>
><br>
>> Dear Teravus:<br>
>><br>
>> No problem. The key point I was trying to make is that as time goes on we<br>
>> seem to be increasing exponentially the storage requirements in the UGAIM<br>
>> assets table. The terrainImage entry was an example of of an 'asset' that is<br>
>> a little different in perception then say, a texture covering a face of a<br>
>> prim.<br>
>><br>
>> This example was intended for us to think about those 'assets' which can be<br>
>> pruned on a regular basis so that our ability from the UGAIM viewpoint to<br>
>> find and retrieve an asset in a timely manner does not get so long as to<br>
>> make our sims performance degraded.<br>
>><br>
>> Charles<br>
>><br>
>> ------------------------------<br>
>> *From:* Teravus Ovares <<a href="mailto:teravus@gmail.com">teravus@gmail.com</a>><br>
>> *To:* <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>> *Sent:* Tuesday, February 17, 2009 6:39:52 AM<br>
>> *Subject:* Re: [Opensim-dev] Please do not revert fixes without careful<br>
>> comtemplation<br>
>><br>
>> I thought it prudent to point out that the following statement is 100%<br>
>> fiction;<br>
>><br>
>> " 2. We have a significant number of assets of each and every edit of<br>
>> terrain, where only the very last one is accessible"<br>
>><br>
>> What I think you meant to say was,<br>
>><br>
>> "2. Every two days each region generates a new map tile image and<br>
>> names it terrainImage. These do eventually add up"<br>
>><br>
>> Best Regards<br>
>><br>
>> Teravus<br>
>><br>
>> On Tue, Feb 17, 2009 at 9:31 AM, Stefan Andersson <<a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a>><br>
>> wrote:<br>
>> ><br>
>> >> > 1. We have a significant number of assets whose name is "blank" that<br>
>> are<br>
>> >> > created with a default constructor. And I suspect are never<br>
>> accessible.<br>
>> >><br>
>> >> In fact, this field has always seemed redundant to me since the user<br>
>> only<br>
>> >> ever manipulates assets by their inventory<br>
>> >> name, which is entirely separate from the asset name. The asset name is<br>
>> >> never visible to the user (and afaik is not<br>
>> >> used anywhere else in the code).<br>
>> >><br>
>> >> At one point I thought about proposing to remove it. Possibly this issue<br>
>> >> should be revisited.<br>
>> ><br>
>> > I believe it's kept there just as a convenience - to be able to get some<br>
>> > kind of semantics, not necessarily exact, when browsing the table.<br>
>> ><br>
>> >> > 2. We have a significant number of assets of each and every edit of<br>
>> >> > terrain, where only the very last one is accessible.<br>
>> >><br>
>> >> Yes, this does seem wasteful to me since old terrain assets are not used<br>
>> >> by anything, afaik.<br>
>> ><br>
>> > I have proposed a number of times that we could have a virtual asset_key<br>
>> as<br>
>> > well as an asset_id - so that things that would rewrite assets could use<br>
>> the<br>
>> > asset_key as an aux method to actually try to overwrite the asset. In the<br>
>> > terrain case, the asset would be overwritten by key, not by id. This<br>
>> would<br>
>> > allow us to implement a number of parallell schemas where some assets<br>
>> would<br>
>> > be overwritten (asset_key = asset_id) and some where we would keep a<br>
>> history<br>
>> > (only asset_key) and some where doing either or would be configurable.<br>
>> ><br>
>> >> > 3. We have a significant number of assets of each and every text edit<br>
>> >> > for each and every textual assets. Where only the last one should be<br>
>> >> > accessible.<br>
>> >><br>
>> >> Unfortunately, this is not the case. For instance, imagine that you<br>
>> create<br>
>> >> a script in your inventory. You drag this<br>
>> >> script into a region object. At this point, both the entry in your<br>
>> >> inventory and the entry in the region point to the<br>
>> >> same textual asset.<br>
>> >><br>
>> >> But then you edit the script in your inventory. After the edit it points<br>
>> >> to a new asset containing the edited text.<br>
>> >> However, the region object is still pointing to the old script asset. So<br>
>> >> we need to keep both the old and new textual<br>
>> >> assets.<br>
>> ><br>
>> > Not to mention the fact that the viewer caches stuff.<br>
>> ><br>
>> >> However, you're right in that textual assets which are never used<br>
>> >> elsewhere (i.e. are intermediate edits that never get<br>
>> >> dragged into an object, given to someone else, or otherwise transmitted)<br>
>> >> might possibly be eliminated with some<br>
>> >> sufficiently careful scheme.<br>
>> ><br>
>> > Binary de-duplication and added semantics in the form of 'key' or 'class'<br>
>> > would probably go a long way.<br>
>> ><br>
>> >> > Its a bit like collecting every scrap of paper ever written with<br>
>> either<br>
>> >> > text or binary glyphs and putting them in a big filing cabinet.<br>
>> >> ><br>
>> >> > After a while, finding the ones that are "interesting" in a "timely"<br>
>> >> > manner starts to get a little "challenging".<br>
>> ><br>
>> > Let's keep the shining torch of this discussion burning.<br>
>> ><br>
>> > /Stefan<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>
>> _______________________________________________<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>
><br>
</div></div>> ------------------------------------------------------------------------<br>
<div><div></div><div class="Wj3C7c">><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>
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>