[Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hey guys,
On the 2.0 profile, Encoding uses the char*/byte* version of encoding
methods to avoid allocating memory. One code path missed this
optimization, I've attached a fix.
This code path ends up being used in Banshee quite a bit on their tree
view (basically, every time the model is queried, this method gets called
in passing String objects to char*).
A few things to think about:
- It might pay to do something on the 1.0 profile as well.
- Paolo, can you comment on how this kind of change works with the moving gc?
-bIndex: Encoding.cs
===
--- Encoding.cs (revision 66966)
+++ Encoding.cs (working copy)
@@ -211,12 +211,18 @@
// Convenience wrappers for "GetByteCount".
public virtual int GetByteCount (String s)
{
- if (s != null) {
- char[] chars = s.ToCharArray ();
- return GetByteCount (chars, 0, chars.Length);
- } else {
+ if (s == null)
throw new ArgumentNullException ("s");
+#if NET_2_0
+ unsafe {
+ fixed (char* cptr = s) {
+return GetByteCount (cptr, s.Length);
+ }
}
+#else
+ char[] chars = s.ToCharArray ();
+ return GetByteCount (chars, 0, chars.Length);
+#endif
}
public virtual int GetByteCount (char[] chars)
{___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Ben Maurer wrote:
> Hey guys,
>
> On the 2.0 profile, Encoding uses the char*/byte* version of encoding
> methods to avoid allocating memory. One code path missed this
> optimization, I've attached a fix.
nice :-) Comment for patch below.
> - It might pay to do something on the 1.0 profile as well.
> - Paolo, can you comment on how this kind of change works with the moving gc?
To my understanding, fixed pointers do not participate GC target. And
- locally-allocated array anyways lives until its conversion finishes
(and probably immediately disposed depending on the JIT optimization)
- Usually this conversion do not take long time
So I guess fixed pointer would work better than possibly being moved
from nursery area.
> + if (s == null)
> throw new ArgumentNullException ("s");
> +#if NET_2_0
> + unsafe {
> + fixed (char* cptr = s) {
> + return GetByteCount (cptr, s.Length);
> + }
> }
> +#else
> + char[] chars = s.ToCharArray ();
> + return GetByteCount (chars, 0, chars.Length);
> +#endif
Before fixing the pointer you have to make sure that s is non-zero length.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Thanks Ben! --Aaron On Wed, 2006-10-25 at 16:51 -0400, Ben Maurer wrote: > Hey guys, > > On the 2.0 profile, Encoding uses the char*/byte* version of encoding > methods to avoid allocating memory. One code path missed this > optimization, I've attached a fix. > > This code path ends up being used in Banshee quite a bit on their tree > view (basically, every time the model is queried, this method gets called > in passing String objects to char*). > > A few things to think about: > > - It might pay to do something on the 1.0 profile as well. > - Paolo, can you comment on how this kind of change works with the moving gc? > > -b > ___ Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
To my understanding, fixed pointers do not participate GC target. And- locally-allocated array anyways lives until its conversion finishes (and probably immediately disposed depending on the JIT optimization)- Usually this conversion do not take long timeSo I guess fixed pointer would work better than possibly being movedfrom nursery area. It's better to not allocate a new array if it can be avoided. From my own code i found that in one of my intensively used methods i allocated a 100byte array each time the method was called. By moving that variable outside the method and just reinitialising it each time i used it (with appropriate locking) memory usage reduced by a large %. Don't rely on the GC to tidy up your mess if you can avoid creating it in the first place :p ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
Hi, Well, the point of the Ben's question is, compacting GC is likely to store array in nursery area (likely, since it could be regarded too big to store in nursery area), so nursery allocation and releasing might become faster than fixing string pointer which might slowdown GC. (That's why BenM asked Paolo, as only he would know the best answer ;-) Atsushi Eno Alan McGovern wrote: >> To my understanding, fixed pointers do not participate GC target. And >> - locally-allocated array anyways lives until its conversion finishes >>(and probably immediately disposed depending on the JIT optimization) >> - Usually this conversion do not take long time >> So I guess fixed pointer would work better than possibly being moved >> from nursery area. > > > It's better to not allocate a new array if it can be avoided. From my own > code i found that in one of my intensively used methods i allocated a > 100byte array each time the method was called. By moving that variable > outside the method and just reinitialising it each time i used it (with > appropriate locking) memory usage reduced by a large %. Don't rely on > the GC > to tidy up your mess if you can avoid creating it in the first place :p > > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Optimize Encoding.GetByteCount
On 10/26/06 Atsushi Eno wrote: > Well, the point of the Ben's question is, compacting GC is likely to > store array in nursery area (likely, since it could be regarded too > big to store in nursery area), so nursery allocation and releasing > might become faster than fixing string pointer which might slowdown GC. Using the fixed keyword has no runtime cost per se (it will have a cost only if a garbage collection is performed while it is in effect). Using fixed (correctly handling empty arrays) is fine in this case. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
