[Opensim-dev] Please do not revert fixes without careful comtemplation

[Melanie]

One of the core developers has tested it. I don't recall who. Any 
indirection can only slow things, it adds processing overhead. If 
NHibernate canbe made faster with indexes, than the same indexes 
will speed up native access even more.
I'm happy I finally took the time to get rid of the MySQL ADO.NET 
wrappers and made the implementation pure native. It is now the 
thinnest layer possible between the driver module and the 
application. I, for one, am not interested in using a juggernaut 
like NHibernate.

Melanie

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