FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DSP goes on a diet.

 
Post new topic   Reply to topic     Forum Index -> DSP
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Wed Mar 30, 2005 10:35 pm    Post subject: DSP goes on a diet. Reply with quote

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:

Arrow 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.

Arrow 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.

Wink

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
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Wed Mar 30, 2005 11:42 pm    Post subject: Reply with quote

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 Rolling Eyes

(this is one of two areas that really bug me about the language)
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Mar 31, 2005 2:20 pm    Post subject: Reply with quote

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 Rolling Eyes

(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. Sad

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?

Very Happy

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
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DSP All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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