• weaselcat (31/31) May 11 2015 here's a single symbol from my project
• Jacob Carlborg (4/6) May 11 2015 Haha :)
• Biotronic (1/1) May 11 2015 https://imgflip.com/i/lcf39
• Martin Nowak (14/15) May 11 2015 The underlying problem is that symbols names grow quadratically
• Walter Bright (6/19) May 11 2015 D already does (for Win32) a generic compression on names. It works a lo...
• Martin Nowak (3/9) May 11 2015 Yeah, that would solve the problem.
• Timon Gehr (12/21) May 12 2015 Not really.
• weaselcat (3/11) May 11 2015 I thought DMC had identical mangling as msvc? Is the D mangling
• Walter Bright (2/4) May 11 2015 C++ mangling is different from D mangling.

"weaselcat" <weaselcat gmail.com> writes:

here's a single symbol from my project

_D3std12experimental6logger4core603__T3logTS3std9algorithm286__T6joinerTC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6joinerFC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6ResultZ3logFNeLS3std9algorithm286__T6joinerTC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6joinerFC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6ResultiAyaAyaAyaAyaZ12__dgliteral7MFNaNiNfZS3std9algorithm286__T6joinerTC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6joinerFC3std11parallelism8TaskPool118__T8asyncBufTS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultZ8asyncBufMFS3std9algorithm77__T9MapResultS357fdsztje2io2IO4ReadMFNekZ9__lambda2TS3std5stdio4File7ByChunkZ9MapResultmZ8AsyncBufZ6Result

that's 1,872 bytes.

but maybe it's just my project, I might have made some serious D
mistakes. I know, I'll check vibe.d


_D3std9exception1355__T11doesPointToTS4vibe4core4core322__T16makeTaskFuncInfoTPFOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4
vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZvTOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC
4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZ16makeTaskFuncInfoFKPFOC4vibe4core7drivers9libevent215Libevent2D
river9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZvKOC4vibe4core7drivers9libevent215Libevent2
Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZ5TARGSTS4vibe4core4core322__T16makeTaskFun
cInfoTPFOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerC
ontextZvTOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14Handler
ContextZ16makeTaskFuncInfoFKPFOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPLi
stenOptionsZ14HandlerContextZvKOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPL
istenOptionsZ14HandlerContextZ5TARGSTvZ11doesPointToFNaNbNiNeKxS4vibe4core4core322__T16makeTaskFuncInfoTPFOC4vibe4core7drivers9libevent215Libevent2Dr
iver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZvTOC4vibe4core7drivers9libevent215Libevent2D
river9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZ16makeTaskFuncInfoFKPFOC4vibe4core7drivers9
libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZvKOC4vibe4core7drivers
9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPListenOptionsZ14HandlerContextZ5TARGSKxS4vibe4core4c
ore322__T16makeTaskFuncInfoTPFOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPLi
stenOptionsZ14HandlerContextZvTOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAyaE4vibe4core3net16TCPL
istenOptionsZ14HandlerContextZ16makeTaskFuncInfoFKPFOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAya
E4vibe4core3net16TCPListenOptionsZ14HandlerContextZvKOC4vibe4core7drivers9libevent215Libevent2Driver9listenTCPMFtDFC4vibe4core3net13TCPConnectionZvAy
aE4vibe4core3net16TCPListenOptionsZ14HandlerContextZ5TARGSZb


hm


compiling vibe.d generates 12 megabytes in symbols, ~75% of them
are completely unable to be demangled by current D demangling
tools.

But surely, phobos couldn't be this bad?

I'd put the symbol here, but it's too long and got rejected by 
the NG. So, you can view it here. https://paste.ee/r/cIuGm

Jacob Carlborg <doob me.com> writes:

On 2015-05-11 11:33, weaselcat wrote:

 I'd put the symbol here, but it's too long and got rejected by the NG.
 So, you can view it here. https://paste.ee/r/cIuGm

Haha :)

-- 
/Jacob Carlborg

"Biotronic" <simen.kjaras gmail.com> writes:

https://imgflip.com/i/lcf39

"Martin Nowak" <code dawg.eu> writes:

On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
 here's a single symbol from my project

The underlying problem is that symbols names grow quadratically 
when combining templated ranges, because each range's name is a 
template argument to the next range. Sometimes name occur twice, 
as template argument and return type.
An obvious solution to the problem is to adopt a compression 
scheme similar to C++ mangling on Windows.
https://github.com/D-Programming-Language/dmd/blob/c392c80c2f04a56701fed3a61a5c4df4571a3573/src/cppmangle.c#L1712

This is a well known and important problem but has a lower 
priority than many other issues. You can help to solve it by 
opening a bugzilla issue (might already exist) and finding out 
how to integrate such a backreference compression with D's 
current mangling.

http://dlang.org/abi.html#MangledName

Walter Bright <newshound2 digitalmars.com> writes:

On 5/11/2015 7:04 AM, Martin Nowak wrote:
 On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
 here's a single symbol from my project

 The underlying problem is that symbols names grow quadratically when combining
 templated ranges, because each range's name is a template argument to the next
 range. Sometimes name occur twice, as template argument and return type.
 An obvious solution to the problem is to adopt a compression scheme similar to
 C++ mangling on Windows.
 https://github.com/D-Programming-Language/dmd/blob/c392c80c2f04a56701fed3a61a5c4df4571a3573/src/cppmangle.c#L1712


 This is a well known and important problem but has a lower priority than many
 other issues. You can help to solve it by opening a bugzilla issue (might
 already exist) and finding out how to integrate such a backreference
compression
 with D's current mangling.

 http://dlang.org/abi.html#MangledName

D already does (for Win32) a generic compression on names. It works a lot
better 
than poorly reinventing compression - it's far less complex, less buggy, easier 
to implement, etc.

I'd support adding a Win32-like compressor. The change I'd make is having it 
only use identifier characters for the compressed result.

"Martin Nowak" <code dawg.eu> writes:

On Monday, 11 May 2015 at 21:18:53 UTC, Walter Bright wrote:
 D already does (for Win32) a generic compression on names. It 
 works a lot better than poorly reinventing compression - it's 
 far less complex, less buggy, easier to implement, etc.

 I'd support adding a Win32-like compressor. The change I'd make 
 is having it only use identifier characters for the compressed 
 result.

Yeah, that would solve the problem.
https://github.com/D-Programming-Language/dmd/blob/932e0a5c2f73b410f0a61ad721e78870ecf17510/src/backend/cgobj.c#L3760

Timon Gehr <timon.gehr gmx.ch> writes:

On 05/12/2015 07:58 AM, Martin Nowak wrote:
 On Monday, 11 May 2015 at 21:18:53 UTC, Walter Bright wrote:
 D already does (for Win32) a generic compression on names. It works a
 lot better than poorly reinventing compression - it's far less
 complex, less buggy, easier to implement, etc.

 I'd support adding a Win32-like compressor. The change I'd make is
 having it only use identifier characters for the compressed result.

 Yeah, that would solve the problem.
 https://github.com/D-Programming-Language/dmd/blob/932e0a5c2f73b410f0a61ad721e78870ecf17510/src/backend/cgobj.c#L3760

Not really.

struct Kill(S,T){}

template Instantiate(size_t n){
     static if(!n) alias Instantiate=Kill!(int,int);
     else{
         alias other=Instantiate!(n-1);
         alias Instantiate=Kill!(other,other);
     }
}

void main(){ Instantiate!100 s; }

This should compile instantaneously and without errors.

"weaselcat" <weaselcat gmail.com> writes:

On Monday, 11 May 2015 at 14:04:07 UTC, Martin Nowak wrote:
 On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
 here's a single symbol from my project

 The underlying problem is that symbols names grow quadratically 
 when combining templated ranges, because each range's name is a 
 template argument to the next range. Sometimes name occur 
 twice, as template argument and return type.
 An obvious solution to the problem is to adopt a compression 
 scheme similar to C++ mangling on Windows.

I thought DMC had identical mangling as msvc? Is the D mangling 
not based on DMC, or am I just wrong on the first assumption?

Walter Bright <newshound2 digitalmars.com> writes:

On 5/11/2015 2:21 PM, weaselcat wrote:
 I thought DMC had identical mangling as msvc? Is the D mangling not based on
 DMC, or am I just wrong on the first assumption?

C++ mangling is different from D mangling.