| View previous topic :: View next topic |
| Author |
Message |
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
 Posted: Wed Mar 30, 2005 10:35 pm Post subject: DSP goes on a diet. |
 |
|
| Code: |
10/11/2004 01:27p <DIR> runtime
03/30/2005 10:01p 1,652 runtime.d
03/30/2005 10:57p 347 runtime.def
03/30/2005 10:57p 348,700 runtime.dll
03/30/2005 11:01p 348,700 runtime.lib
03/30/2005 11:02p 378,646 runtime.map
03/30/2005 11:01p 553 runtime.obj
03/30/2005 10:57p 2,232 runtime.rsp
7 File(s) 1,080,830 bytes
1 Dir(s) 1,441,038,336 bytes free
|
Nevermind the fact that I'm running out of hard-drive space.
The DSP runtime, is entirely too large, possibly due to the fact that it's pulling in a sizeable chunk of mango to support servlets.
The problem here is that presently, every servlet that gets compiled will incorporate that .3MB of code. Even if I redesign the server to fold an entire applciation into a single .dll, this is still too much overhead.
So far, I can strip it down to 80K with the typelibrary/dll support using "-release -O -inline", so I'll consider that the floor for now. I blame phobos for the rest of the pork in there.
This quick analysis points at a reducing the overhead for any given servlet will yield huge dividends in terms of performance and memory consumption. This means that I'll now have to change tact slightly:
 At some point, DSP will have to be able to compile whole applications into a single dll for use. An alternative would be to allow some sort of grouping either by directives in the DSP code itself, or by directory. I may want to keep it as an optional feature as it could impact development cycles significantly.
Servlets can't be Mango-Servlet-Class based due to the inherent overhead. I will follow suit with similar technologies, and use a single-funciton handler to represent a .dsp page instead. The benefits here are huge: less DSP grammar, smaller parser, faster execution, less coupling between servlet and server and and just plain easier to grok.
I wanted to model things after the ASP.NET approach of representing a page with a whole class. In retrospect, this actually puts a lot of weight on the programmer, as extending a given page has all sorts of class-like implications; its not what the typical ASP programmer expects. Also, any runtime (Java too) can have flyweight assemblies and compiled bits of code since bytecode environments are just slick like that. Since DSP operates in the trenches along with the OS and everything else, design compromises have to be made.
Overall, it means incorporating what I've learned from writing CML, which is a few months ahead of DSP at this point.
So what about a runtime library? I've been brainstorming on what could be done here. In the long-run I hope to back a sandboxed Ares release, but in the meantime, I'll be rolling some support libs once Beta 1 gets off the ground. Phobos already has most of what one needs, and DB access is already covered in at least two other projects. XML support will have to come along, one way or the other.
I *will* be working on an AJAX-like library that will allow for refreshless application designs. I sketched out some code today that was lightweight and could do the job, but D's templates need some kinks worked out first. So the inital API for this is going to be really raw.
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Mar 30, 2005 11:42 pm Post subject: |
|
|
It's worth pointing out that the overhead issue is a problem relating to the lack of usable-dynamic-loading within D itself.
I've abandoned all hopes of using DLL's for things like servlets, and mobile-code, until the language has realistic support. By that, I mean directly linkable D methods (to a DLL), compiler generated import-files for DLL based modules, and a non-phsycotic mechanism to handle both the GC and the thread-pool at runtime. Not to mention the whole typeinfo thing you ran into.
Note that the servlet engine was up and running almost a year ago, yet we're still waiting for usable DLL support. Frankly, D is a farce in this particular space. Whilst this is clearly a very low priority, one hopes the notion of dynamically loadable code will eventually be seriously considered 
(this is one of two areas that really bug me about the language) |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Thu Mar 31, 2005 2:20 pm Post subject: |
|
|
| kris wrote: | It's worth pointing out that the overhead issue is a problem relating to the lack of usable-dynamic-loading within D itself.
I've abandoned all hopes of using DLL's for things like servlets, and mobile-code, until the language has realistic support. By that, I mean directly linkable D methods (to a DLL), compiler generated import-files for DLL based modules, and a non-phsycotic mechanism to handle both the GC and the thread-pool at runtime. Not to mention the whole typeinfo thing you ran into.
Note that the servlet engine was up and running almost a year ago, yet we're still waiting for usable DLL support. Frankly, D is a farce in this particular space. Whilst this is clearly a very low priority, one hopes the notion of dynamically loadable code will eventually be seriously considered
(this is one of two areas that really bug me about the language) |
Its as though I'm trying to scale K-2 only to double-check my map and discover that I'm half-way up Everest instead. Your discouragement is all too familiar. 
I think the problem here is that there's a complete lack of good research in this area. D itself has every capability to make things work as we'd expect on other platforms (Java and .NET) but they require us to eschew legacy compatibility and cram the language full of new/exotic features. I think the latter is what's hurting the move forward. In the face of proper support for such things, we're left to hack against the ABI and pork our code full of messy mixins and such.
I've hacked around the problem for long enough to see what is needed.
D needs to provide a way to late bind the type tree that a given Dll needs to run, at a given degree of compatibilty with its host. Garbage-collected Dlls are a close second and the third, GC integration has already been completed.
With respect to binding the type tree, it would eliminate the problems with type casting and overhead size while eliminating proxies and COM-like setups. If this sounds familiar, it should, as its the way Java tackles this issue with .class files.
(I can stand keeping proxies around to emulate week references for dll-reload semantics... its' a strange problem space to begin with so I wouldn't expect it to belong in the language properly.)
Its a hard task, that involves either keeping a text name or UUID around in a given .exe so it can be used for binding activities. Also it means compiling a dll with a designated number of classes and typeinfo stubs, to be bound at a later point.
Were types compared via UUID, for instance, the all the DLL would need is a single binding pass to plug in the v-tables, and general Typeinfo. At worst, we're looking at the compiler generating the mother of all fixup tables to re-write references to typeinfo pointers (yuck!).
I suppose its the kind of thing that could be left out via a compiler switch, should the overhead hurt other styles of applications.
... I wonder if there's enough elbow-room in the ABI to accomplish some of this?
Anyway, I'm going to stay the course and see what comes of this. If for no other reason, the research that drops from this should help others.
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
