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

Thu Feb 19 11:59:19 UTC 2009

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090219/c715fbe1/attachment-0001.html>