7

This post has the comment if you need to call the method multiple times, use reflection once to find it, then assign it to a delegate, and then call the delegate..

  • How and why does this delegate work faster? Can anyone has some example?
  • Can I call this caching? If so, are there any other method than this caching method with delegate?

ADDED

I came up with an example of using delegate here.

Community
  • 1
  • 1
prosseek
  • 182,215
  • 215
  • 566
  • 871

5 Answers5

4

A delegate is simply a pointer to a function. If you're using reflection (at all) there is generally a lot of overhead associated with it. By finding this methods address once and assigning that address to your delegate variable, you are in effect caching it.

So, it's not the "delegate" type that works faster, it's just that you're "computing" once and "using" it multiple times that grants you the speed increase.

Brandon Moretz
  • 7,512
  • 3
  • 33
  • 43
  • A delegate is not a pointer. Managed C# code does not have pointers. It has references. No variable in managed C# code holds memory addresses (unless you're doing some nasty work intentionally meant for that). – Neowizard Jun 21 '11 at 19:02
  • 2
    @Neowizard I appreciate the nit-picking, however I call a spade a spade. – Brandon Moretz Jun 21 '11 at 19:05
  • @Brandon think about the lambda () => x++; where x is a local var in the method defining the lambda. If a delegate is just a pointer, then where is this lambda stored in memory and why is there a reference to x there? Like Haris said, delegates are not pointers they are objects who hold an instance (or more accurately a instance scope) and a method (call it a pointer to a method if you must). The concept of Lambda/Delegate is derived from functional programming where the concept of pointers usually doesn't even exists. – Neowizard Jun 21 '11 at 19:11
  • 1
    @Neowizard the *concept* is the same, and has been the same since Dennis Ritchie introduced it via the "C" language. In your example, "x" is a local variable scoped to that particular function, it DOES NOT have anything to do with the "owning" function entry point being an ADDRESS in memory. Call that address a "reference" or a "pointer", it does not matter. – Brandon Moretz Jun 21 '11 at 19:20
  • @Brandon that's just it, I'm not calling the address anything, there is no address to begin with. Saying that a delegate is a pointer to a function is like saying that C# String is no different then C's char*, and if that's what you're saying then this is not the right place for this mild debate to begin with. – Neowizard Jun 21 '11 at 19:31
  • You can colloquially call it a pointer but a delegate encapsulates the method **and the instance it will be called on**. C# delegates are closer to C++ functors than they are to C function pointers. – Rick Sladkey Jun 21 '11 at 20:36
  • @Rick Isn't a C++ functor *essentially* a wrapper object around a function pointer (as is a delegate)? o_O – Brandon Moretz Jun 21 '11 at 20:45
  • @Brandon: A functor also wraps the target, as does a delegate. So you can't use one delegate to call the same method on two or more different instances. That's why it's misleading to say the delegate conceptually is just the address of the method. It's a nit but worth understanding. – Rick Sladkey Jun 21 '11 at 20:52
  • @Rick I agree with that point completely. What I don't agree with is saying that "functions have no address in memory" which is what started this stupid debate in the first place. – Brandon Moretz Jun 21 '11 at 20:56
  • @Brandon if you're referring to me, I never said that functions have no address in memory, I said that no variable in managed C# stored memory addresses. – Neowizard Jun 21 '11 at 21:29
  • @Neowizard http://msdn.microsoft.com/en-us/library/system.intptr%28v=vs.71%29.aspx. And I quote, "I'm not calling the address anything, there is no address to begin with."... ಠ_ಠ – Brandon Moretz Jun 21 '11 at 21:30
  • @Brandon right there is no address to begin with when you are talking about a delegate (or any object for that matter). It's obvious that memory will be addressed eventually (the code need to run on a computer eventually), but that really has nothing to do with this discussion – Neowizard Jun 21 '11 at 21:36
  • @Neowizard Object o = new Object(); Exactly what does o contain? – Brandon Moretz Jun 21 '11 at 21:38
  • @Neowizard Sorry, I forgot no one writes software that actually gets executed on hardware at some point. It's all just magical IL objects doing God's work. – Brandon Moretz Jun 21 '11 at 21:40
  • Regarding the link, IntPtr is used for pointer support mainly, which is not used in managed C# code, and furthermore, I don't see how it relates to delegates. – Neowizard Jun 21 '11 at 21:40
  • @Brandon I'm sorry I've upset you, but the point still remains. In regards to your question the result of Object o = new Object(); is that in o there will be a reference into the runtime reference table (what is contained in that table is probably memory address GC-related info and probably some more stuff). Also, I never said that code isn't run, I said that if you want to talk about what a delegate is, then the implementation of the runtime isn't relevant. And regarding your last comment, like I said, I'm sorry that I've upset you. – Neowizard Jun 21 '11 at 23:30
1

Delegate.CreateDelegate

Probably the best docs on MSDN :)

leppie
  • 115,091
  • 17
  • 196
  • 297
1

Obviously it will work faster because of the reduced overheard caused by reflection. If you follow the tip, you won't go for reflection each time rather you will store reference in a delegate and hence you are reducing cost by not redoing the reflection. So yes, it will act like caching i guess once you are storing reference in a delegate in a sense that you won't have to go to reflection again

Haris Hasan
  • 29,856
  • 10
  • 92
  • 122
1

Fist off, this is not caching. You are not saving a copy of the method in a "closer" location, you're just holding on to a reference to that method.

Think about the steps needed to take in order to call a method using reflection (accessing the reflation data from the assembly, looking up the method/namespace/class by name and more...), the last step is getting a reference (and don't let anyone tell you that a delegate is a pointer!) to the method and invoking it. When you use a delegate you only take the last step, and save yourself all that headache that comes with reflection.

Neowizard
  • 2,981
  • 1
  • 21
  • 39
1

Isn't it obvious. You load the assembly into your app domain; create an instance of the type, and then create a delegate pointing to that instance's method...

deostroll
  • 11,661
  • 21
  • 90
  • 161