Slow performance compared to C++, ideas?

deadalnix deadalnix at gmail.com
Mon Jun 3 23:49:30 PDT 2013


On Tuesday, 4 June 2013 at 06:23:18 UTC, Jonathan M Davis wrote:
> The idea is that any function which isn't overridden shouldn't 
> be virtual.
> However, in the normal case, there's no way of knowing whether 
> a class will be
> derived from or whether any particular function will be 
> overidden. Code can be
> compiled separately such that the compiler has no clue what 
> derived classes
> exist.
>
> However, in the case where you have a shared library and all 
> symbols which
> will be used outside of the library must be exported, the 
> linker could
> theoretically examine every function which is not exported and 
> make it non-
> virtual if it's not being overridden, because no code outside 
> of the shared
> library could possible override it.

Yes.

> This will only help functions which aren't
> exported, and will only work on Windows, as no other platform 
> currently
> requires that symbols be explicitly exported.

It can't work on windows right now, as export's semantic is not 
strong enough (it do not apply to virtual methods).

The proposal is to make export stringer (IE, makes it impossible 
to override class that aren't exported in a shared lib, on all 
systems.

Today's linker support the functionnality.

> It also requires that the linker
> do this, and as long as we're using the C linker, I don't know 
> how it could.

linkers from GCC and LLVM toolchains allow for LTO. The concept 
is to dump the IR in the object file, so a compiler aware of it 
can run additional optimization at link time.

I don't know how hard it is for GCC, but for LLVM, what needs to 
be done is for the frontend to dump the right metadata into the 
IR, so an optimizing pass can remove unneeded virtual calls.

We can do it in a D specific way (using our own metadata and 
providing an optimization pas for LLVM) but most likely we won't 
even need to as the same feature is planned to be added to clang 
and we can most likely simply reuse clang's metadata.


More information about the Digitalmars-d mailing list