On Thu, Dec 23, 1999 at 10:56:46AM +0100, Andre' Poenitz wrote:
And could have some more advantages. You could 'register' new functions
at run time. You do not need a monolithic 2MB+ binary when you
use only 10% of the functionality.
Just load 'modules' dynamically on demand...
Gawd, I
And could have some more advantages. You could 'register' new functions
at run time. You do not need a monolithic 2MB+ binary when you
use only 10% of the functionality.
Just load 'modules' dynamically on demand...
Gawd, I wish I knew how to code that! If I did, I'd contribute
On 23 Dec 1999 20:22:39 +0100, Lars Gullik Bj°nnes wrote:
|
| Some time ago I suggested to use 'static inline' to break fn's up. I
| think this should work without of introducing fn call overhead.
inlining is one of the fings that really slows a compilation...
I see... Re-inlining fn's
On Thu, Dec 23, 1999 at 10:56:46AM +0100, Andre' Poenitz wrote:
>
> And could have some more advantages. You could 'register' new functions
> at run time. You do not need a monolithic 2MB+ binary when you
> use only 10% of the functionality.
> Just load 'modules' dynamically on demand...
Gawd,
> > And could have some more advantages. You could 'register' new functions
> > at run time. You do not need a monolithic 2MB+ binary when you
> > use only 10% of the functionality.
> > Just load 'modules' dynamically on demand...
>
> Gawd, I wish I knew how to code that! If I did, I'd
On 23 Dec 1999 20:22:39 +0100, Lars Gullik Bj°nnes wrote:
>|
>| Some time ago I suggested to use 'static inline' to break fn's up. I
>| think this should work without of introducing fn call overhead.
>
>inlining is one of the fings that really slows a compilation...
I see... Re-inlining fn's
Allan Rae [EMAIL PROTECTED] writes:
| function table instead? A vector indexed by function number or a hash_map
| perhaps? This is easy enough to implement.
No, not a function table... more a split into several despatchers,
LyX::dispatch, LyXView::dispatch, BufferView::dispatch
| At the
So you'd like to ditch the giant switch statement and replace it with a
function table instead? A vector indexed by function number or a hash_map
perhaps? This is easy enough to implement.
And could have some more advantages. You could 'register' new functions
at run time. You do not need a
On 22 Dec 1999 14:33:03 +0100, Lars Gullik Bj°nnes wrote:
"Andre' Poenitz" [EMAIL PROTECTED] writes:
| of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
|
|
| Optimize less (or dont't optimize at all), use only small
| functions.
|
| Well. The second part *is*
Allan Rae <[EMAIL PROTECTED]> writes:
| > > function table instead? A vector indexed by function number or a hash_map
| > > perhaps? This is easy enough to implement.
No, not a function table... more a split into several despatchers,
LyX::dispatch, LyXView::dispatch, BufferView::dispatch
|
> So you'd like to ditch the giant switch statement and replace it with a
> function table instead? A vector indexed by function number or a hash_map
> perhaps? This is easy enough to implement.
And could have some more advantages. You could 'register' new functions
at run time. You do not
On 22 Dec 1999 14:33:03 +0100, Lars Gullik Bj°nnes wrote:
>"Andre' Poenitz" <[EMAIL PROTECTED]> writes:
>
>| > of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
>| >
>| >
>| >Optimize less (or dont't optimize at all), use only small
>| > functions.
>|
>| Well. The
On Wed, 22 Dec 1999 12:59:28 +1000 (GMT+1000), Allan Rae wrote:
ven with 128MB of RAM and dual 400MHz processors it takes twice as long
to compile with SGI's string and _no_ exceptions as it does to compile lyx
with the lyx supplied string _and_ exceptions! (12minutes vs 6minutes)
The only
of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
Optimize less (or dont't optimize at all), use only small
functions.
Well. The second part *is* helpful...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
"Andre' Poenitz" [EMAIL PROTECTED] writes:
| of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
|
|
| Optimize less (or dont't optimize at all), use only small
| functions.
|
| Well. The second part *is* helpful...
And this is why it takes lyx two hours to
On Thu, Dec 23, 1999 at 02:21:11PM +1000, Allan Rae wrote:
On 22 Dec 1999, Lars Gullik Bjønnes wrote:
And this is why it takes lyx two hours to compile on the new stdlib++,
1 hour of that time is lyxfunc...
reducing function size will speed up compilation time a lot.
So you'd like
On Wed, 22 Dec 1999 12:59:28 +1000 (GMT+1000), Allan Rae wrote:
>ven with 128MB of RAM and dual 400MHz processors it takes twice as long
>to compile with SGI's string and _no_ exceptions as it does to compile lyx
>with the lyx supplied string _and_ exceptions! (12minutes vs 6minutes)
>The only
> of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
>
>
> Optimize less (or dont't optimize at all), use only small
> functions.
Well. The second part *is* helpful...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
"Andre' Poenitz" <[EMAIL PROTECTED]> writes:
| > of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:
| >
| >
| > Optimize less (or dont't optimize at all), use only small
| > functions.
|
| Well. The second part *is* helpful...
And this is why it takes lyx two hours
On Thu, Dec 23, 1999 at 02:21:11PM +1000, Allan Rae wrote:
> On 22 Dec 1999, Lars Gullik Bjønnes wrote:
>
> > And this is why it takes lyx two hours to compile on the new stdlib++,
> > 1 hour of that time is lyxfunc...
> >
> > reducing function size will speed up compilation time a lot.
>
>
20 matches
Mail list logo
