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

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

https://imgflip.com/i/lcf39

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

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.

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?

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.

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

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.