[Mono-dev] ASP.NET 2.0 performance discussion.
grendel at caudium.net
Thu Nov 23 12:44:13 EST 2006
On Thu, 23 Nov 2006 12:11:44 -0500, Miguel de Icaza <miguel at ximian.com>
> > Yes, but it's a big effort - MS.NET browser definitions are above
> > 10k lines of XML. It's especially hard that the new XML database
> > matches also on headers other than the UA.
> The complexity of the Microsoft XML file is due to the fact that they
> are more clever than the approach we are using, they use regular
> expressions to shrink that file down from what we have.
True. In addition, they support much more browsers than we do, and they
have split the files into per-browser sets.
> But consider that we can not use their database (we can not
> redistribute it) and considering that we have a very good solution
> today, which is maintained by an active maintainer that tracks the
> same data in a simpler format, it does not make sense to support the
> MS format (except for corner compatibility cases, and I think we are
> much better off with having users update the files we ship).
True, but we also need to suport ~/App_Browsers, and that requires us
to implement the support for the .browser format anyway. But I agree
that using whatever we have today internally is perfectly fine
(especially with resources like
http://browsers.garykeith.com/downloads.asp where the files are kept
fairly up to date).
> So we will be avoiding the full cost of a full regular expression
> match, our file does not require that complexity.
True. I've just thought about yet another optimization. What if we
shipped a file (for internal use only) that contained full collection of
UAs paired with their hash and the serialized browser caps objects? We
could then load the file to prime the UA cache I talked about and use
hash values to look for matches. Any new UAs, not found in our cache,
would of course be treated the "long way" first. What do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20061123/53ee1038/attachment.bin
More information about the Mono-devel-list