Bug 111

Summary:	Ptr<Packet> is slower than raw Packet
Product:	ns-3	Reporter:	Mathieu Lacage <mathieu.lacage>
Component:	core	Assignee:	Mathieu Lacage <mathieu.lacage>
Status:	RESOLVED WONTFIX
Severity:	enhancement	CC:	mathieu.lacage, ns-bugs, tommaso.pecorella
Priority:	P3
Version:	pre-release
Hardware:	All
OS:	All

Description Mathieu Lacage 2007-11-22 04:42:17 UTC

This is the case since we switched to Ptr<Packet>. It is due to two things:
  - Ref/Unref are not inlined
  - Packet needs a free list

So, we need to fix both issues and verify that the new free list does not interact badly with the other free lists in Buffer, PacketMetadata, and, Tags.

Comment 1 Mathieu Lacage 2009-11-23 08:28:01 UTC

ref/unref are not inlined anymore.

We still need to go back seriously to the packet code and try to figure out if a packet free list would help. Marking as enhancement.

Comment 2 Tommaso Pecorella 2012-03-15 20:45:40 UTC

C++11, n3337.pdf, page 527, section 20.7
20.7.2 Shared-ownership pointers
The shared_ptr class template stores a pointer, usually obtained via new. 
shared_ptr implements semantics of shared ownership; the last remaining owner 
of the pointer is responsible for destroying the object, or otherwise releasing 
the resources associated with the stored pointer. A shared_ptr object is empty 
if it does not own a pointer.

Comment 3 Mathieu Lacage 2012-03-16 03:19:04 UTC

and ?

Comment 4 Tommaso Pecorella 2012-03-16 04:52:56 UTC

Ref and Unref will be handled at compiler-level (most probably using the new atomic types).

The shared_pointer seems to have many functionalities actually handled by SimpleRef and Ptr, so the ns-3 implementation could benefit from shared_pointers. The performance will, of course, depend on the compiler smartness. However I'd expect a faster (and simpler) implementation using them.

All still speculative, but we could do a couple of tests right now, as some compilers are already supporting C++11 draft.

The drawback would be to drop the "old" compilers support, so it's something we don't want to do right now. On the long run, tho, it's something to keep in mind.

T.

Comment 5 Mathieu Lacage 2012-03-16 05:01:05 UTC

Actually, Ref and Unref are inlined now. And to answer your comment about shared_ptr, I do not believe that we will ever migrate because I do not believe we can do this compatibly (I might be wrong though) and the pain involved to break everything seems way too high.

To answer your other comments about shared_ptr:
1) no, they are not handled specifically at the compiler level
2) no, they will not use atomics because they are not guaranteed to be thread-safe, and you are happy they do not because the performance cost of doing this would be horrendous.

Comment 6 Mathieu Lacage 2012-03-16 05:01:56 UTC

bwwwah. I am going to close that bug, unless someone has specific suggestions on how to speedup our code.

Comment 7 Tommaso Pecorella 2012-03-16 06:35:04 UTC

I agree on closing this, at least until someone finds a real use-case where the performance hit is a real problem.

About the shared_pointer, the comment was originated because I'm too curious about what we can do with C++11 and how it would affect the actual codebases (not just the ns-3 one).
I do agree that it would a pain to migrate, plus it's always good to keep in mind the Rules

Rule:
Don't change what's not broken.
Corollary (for engineers):
Everything can be classified in two broad areas: "broken" and "can be improved".

T.