-------- Original Message --------
Ben Maurer wrote: "Accessing" is not a point. The initialization of such array is root of troubles. I have no raw benchmarkOn Sat, 2005-06-11 at 09:43 +0300, Ilya Kharmatsky wrote:In "empty page" benchmark - under heavy stress - it took 3-5% of overall server side job. I'm talking about "empty page", where no too much flows works.Wow. How much slower are you on a raw benchmark of accessing a struct array? but this cost will be proportional to length of array * "new". Since, currently I'm on vocation - I cannot run it and say you exact numbers. Since each request - created new instanced of these arrays - we got the problem.Given those numbers, it seems like struct member access is a few orders of magnitude slower than it should be. Sounds like something that needs to be fixed at the source... A 3-5% improvement on web requests makes for a nice incentive! I don't know exact numbers - but it shouldn't be a problem.BTW, doesn't this show up with Hashtable, which also uses an array of structs?In Grasshopper we are using completely different implementation of Hashtable (BTW our implementation doesn't use structs and works faster then mono's original hashtable and msft hashtable).How about in terms of memory usage? I have no benchmarks currently , it depends also on operation (Add, Remove, ContainsKey).Care to share? Have benchmarks? When I'll be back in office I'll send the benchmarks and code - but our code has been strongly influenced by : http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.html (you can download code from here: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html check "installation" part) As I told, when I'll return to office - I'll send our version of Hashtable.cs Ilya. |
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list