[Mono-dev] [PATCH] Redirect certain string constructors to CreateString

Zoltan Varga vargaz at gmail.com
Sun Jul 16 09:28:50 EDT 2006


                   Hi,

 Just add it to the relevant header file.

              Zoltan

>
> How difficult would it to introduce a MONO_WRAPPER_MANAGED_TO_MANAGED
> wrapper type?
>
> Kornél
>
> ----- Original Message -----
> From: "Zoltan Varga" <vargaz at gmail.com>
> To: "Kornél Pál" <kornelpal at gmail.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Sunday, July 16, 2006 1:55 PM
> Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors to
> CreateString
>
>
>                                                Hi,
>
>   Thinking about it, I think the runtime_invoke () based approach is
> better. It might not have
> the best performance,  but it doesn't have the problems with the
> wrapper based approach.
> Also, some of the perf overhead is by mono_runtime_invoke () which
> needs to be find
> the compiled version of the runtime invoke wrapper etc. Later, we
> could add an API to
> look this up and cache it, making this much faster. If you go with the
> wrapper based
> approach, you should add a new wrapper type, since MANAGED_TO_NATIVE is for
> calling native code, and a lot of runtime parts depend on this.
>
>                                  Zoltan
>
> On 7/16/06, Kornél Pál <kornelpal at gmail.com> wrote:
> > Hi,
> >
> > The previous test results were incorrect. And I added this time I cached
> > the
> > result of mono_class_get_method_from_name ().
> >
> > I used the same test with the following parameters:
> > string length: 8; iterations: 10000000
> > string length: 128; iterations: 10000000
> > string length: 4096; iterations: 1000000
> >
> > And I got the following results for call:
> > 6562
> > 13922
> > 35031
> >
> > And the following for invoke:
> > 14750
> > 23141
> > 37047
> >
> > Altough the measures in my previous message were incorrect, a
> > managed-to-managed wrapper is much faster.
> >
> > Kornél
> >
> > ----- Original Message -----
> > From: "Kornél Pál" <kornelpal at gmail.com>
> > To: "Zoltan Varga" <vargaz at gmail.com>
> > Cc: <mono-devel-list at lists.ximian.com>
> > Sent: Sunday, July 16, 2006 5:40 AM
> > Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors to
> > CreateString
> >
> >
> > > Hi,
> > >
> > > Using mono_runtime_invoke () is simpler indeed but it's much slower than
> > > using managed only implementation. Using the attached test I got 19265
> > > for
> > > CEE_CALL while 34672 for mono_runtime_invoke (). So I think it's worth
> > > to
> > > generate managed wrappers unless they cause some serious problems.
> > >
> > > Is it OK to use MONO_WRAPPER_MANAGED_TO_NATIVE for the generated
> > > managed-to-managed wrappers to be consistent with other icalls?
> > >
> > > Kornél
> > >
> > > ----- Original Message -----
> > > From: "Zoltan Varga" <vargaz at gmail.com>
> > > To: "Kornél Pál" <kornelpal at gmail.com>
> > > Cc: <mono-devel-list at lists.ximian.com>
> > > Sent: Sunday, July 16, 2006 1:40 AM
> > > Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors to
> > > CreateString
> > >
> > >
> > >                              Hi,
> > >
> > >  I would prefer the wrapper approach. Another (simpler) approach
> > > would be to simply
> > > call the CreateString methods from the unmanaged ctors using
> > > mono_runtime_invoke ().
> > >
> > >                Zoltan
> > >
> > > On 7/15/06, Kornél Pál <kornelpal at gmail.com> wrote:
> > >> Hi,
> > >>
> > >> Could you please let me know which solution do you prefer? (redirecting
> > >> .ctor to CreateString or using a wrapper that calls CreateString)
> > >>
> > >> According to my test using a wrapper makes the code slower. I tried to
> > >> use
> > >> CEE_JMP as well but in that case .ctor is lost from the stack trace as
> > >> well
> > >> so I think there is no use to create a wrapper using CEE_JMP.
> > >>
> > >> Thanks for your help.
> > >>
> > >> Kornél
> > >>
> > >> ----- Original Message -----
> > >> From: "Kornél Pál" <kornelpal at gmail.com>
> > >> To: "Zoltan Varga" <vargaz at gmail.com>
> > >> Cc: <mono-devel-list at lists.ximian.com>
> > >> Sent: Thursday, July 13, 2006 2:48 PM
> > >> Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors to
> > >> CreateString
> > >>
> > >>
> > >> > Hi,
> > >> >
> > >> > I reallized that simply redirecting the method may not be a good
> > >> > solution
> > >> > because the .ctor method is lost from the stack trace this way. And I
> > >> > think
> > >> > other problems may occur altough I never experienced such problems.
> > >> >
> > >> > I attached an extended version of the previous patch that creates a
> > >> > wrapper.
> > >> >
> > >> > In addition now CreateString () methods are properly implemented and
> > >> > I've
> > >> > patched ASCIIEncoding and Latin1Encoding classes so that their
> > >> > GetString
> > >> > ()
> > >> > methods no longer recurse to CreateString () methods.
> > >> >
> > >> > If these modifications are approved I'll commit this patch and later
> > >> > it
> > >> > will
> > >> > be easier to extend CreateString () to use faster method
> > >> > implementations
> > >> > for
> > >> > internal encoding classes. (I changed my mind.:)
> > >> >
> > >> > Kornél
> > >> >
> > >> > ----- Original Message -----
> > >> > From: "Kornél Pál" <kornelpal at gmail.com>
> > >> > To: "Zoltan Varga" <vargaz at gmail.com>
> > >> > Cc: <mono-devel-list at lists.ximian.com>
> > >> > Sent: Wednesday, July 12, 2006 5:27 PM
> > >> > Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors
> > >> > to
> > >> > CreateString
> > >> >
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> CreateString methods are not yet complete. The attached CreateString
> > >> >> methods were forged for testing only.
> > >> >>
> > >> >> Encoding.GetString() methods are currently using new String (char
> > >> >> [])
> > >> >> so
> > >> >> the performance gain were probably insignificant and
> > >> >> Latin1Encoding.GetString () methods currently use new String
> > >> >> (sbyte*,
> > >> >> int,
> > >> >> int) that would result in infinite recursion.
> > >> >>
> > >> >> I'm going to check-in the modifications made to the runtime after I
> > >> >> finish
> > >> >> the work on Encoding classes. (And when those modifications will be
> > >> >> approved as well.)
> > >> >>
> > >> >> Thanks for the approval and your help in implementing the code.
> > >> >>
> > >> >> Kornél
> > >> >>
> > >> >> ----- Original Message -----
> > >> >> From: "Zoltan Varga" <vargaz at gmail.com>
> > >> >> To: "Kornél Pál" <kornelpal at gmail.com>
> > >> >> Cc: <mono-devel-list at lists.ximian.com>
> > >> >> Sent: Wednesday, July 12, 2006 4:30 PM
> > >> >> Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors
> > >> >> to
> > >> >> CreateString
> > >> >>
> > >> >>
> > >> >>           Hi,
> > >> >>
> > >> >> This looks ok to check-in, except the Console.WriteLine in
> > >> >> CreateString
> > >> >> ().
> > >> >>
> > >> >>        Zoltan
> > >> >>
> > >> >> On 7/12/06, Kornél Pál <kornelpal at gmail.com> wrote:
> > >> >>> Attached a modified version. Using a function instead of (-1) is a
> > >> >>> good
> > >> >>> idea
> > >> >>> not because g_assert_not_reached () can be used but because (-1)
> > >> >>> will
> > >> >>> not
> > >> >>> be
> > >> >>> monopolized to string constructors (altought it's very unlikely to
> > >> >>> need
> > >> >>> any
> > >> >>> other kind of redirection).
> > >> >>>
> > >> >>> And I added two more g_asserts to ensure that CreateString methods
> > >> >>> are
> > >> >>> implemented using managed code.
> > >> >>>
> > >> >>> If you have any other comments please let me know.
> > >> >>>
> > >> >>> Kornél
> > >> >>>
> > >> >>> ----- Original Message -----
> > >> >>> From: "Zoltan Varga" <vargaz at gmail.com>
> > >> >>> To: "Kornél Pál" <kornelpal at gmail.com>
> > >> >>> Sent: Wednesday, July 12, 2006 12:43 PM
> > >> >>> Subject: Re: [Mono-dev] [PATCH] Redirect certain string
> > >> >>> constructors
> > >> >>> to
> > >> >>> CreateString
> > >> >>>
> > >> >>>
> > >> >>>                                          Hi,
> > >> >>>
> > >> >>>   This approach seems workable. It would be better to have a dummy
> > >> >>> string
> > >> >>> ctor (eg ves_icall_System_String_ctor_CreateString with a body of
> > >> >>> g_assert_not_reached ()) instead of the ICALL_... constant.
> > >> >>> Probably
> > >> >>> only
> > >> >>> mono_marshal_lock () is needed.
> > >> >>>
> > >> >>> On 7/11/06, Kornél Pál <kornelpal at gmail.com> wrote:
> > >> >>> > The previous one did not cache the results. Now this is fixed.
> > >> >>> >
> > >> >>> > BTW is mono_loader_lock () and mono_marshal_lock () necessary as
> > >> >>> > well?
> > >> >>> >
> > >> >>> > Kornél
> > >> >>> >
> > >> >>> > ----- Original Message -----
> > >> >>> > From: "Kornél Pál" <kornelpal at gmail.com>
> > >> >>> > To: <mono-devel-list at lists.ximian.com>
> > >> >>> > Sent: Tuesday, July 11, 2006 9:20 AM
> > >> >>> > Subject: [PATCH] Redirect certain string constructors to
> > >> >>> > CreateString
> > >> >>> >
> > >> >>> >
> > >> >>> > > Hi,
> > >> >>> > >
> > >> >>> > > The attached patch implements what I was planning to do.
> > >> >>> > >
> > >> >>> > > Note that if the patch is approved I'm not going to commit is
> > >> >>> > > yet
> > >> >>> > > because
> > >> >>> > > the encoding classes should be updated first.
> > >> >>> > >
> > >> >>> > > This patch contains String.cs modifications as well that should
> > >> >>> > > compile
> > >> >>> > > with
> > >> >>> > > the current encoding classes as well.
> > >> >>> > >
> > >> >>> > > I think this is a good solution and works for me but comments
> > >> >>> > > are
> > >> >>> > > welcome.
> > >> >>> > >
> > >> >>> > > Please review and approve the patch.
> > >> >>> > >
> > >> >>> > > Kornél
> > >> >>> > >
> > >> >>> >
> > >> >>> >
> > >> >>> > _______________________________________________
> > >> >>> > Mono-devel-list mailing list
> > >> >>> > Mono-devel-list at lists.ximian.com
> > >> >>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > >> >>> >
> > >> >>> >
> > >> >>> >
> > >> >>> >
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>



More information about the Mono-devel-list mailing list