Andre Poenitz [EMAIL PROTECTED] writes:
| I'd actually prefer to put one-liners directly in the class definition in
| my own coding as a matter of convienience and better readability, too. Of
| course, the latter is arguable, but if I see
|
|size_type size() const
| { return
Yes, but too often this is not one-liners, but two-liners on one line:
size_type size() const { Assert(...); return data_.size(); }
Those are gone now, aren't they? ;-)
Ok, I admit, my personal limit in such cases is about four lines, i.e.
usually one or two initializations, and call
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I'd actually prefer to put one-liners directly in the class definition in
| my own coding as a matter of convienience and better readability, too. Of
| course, the latter is arguable, but if I see
|
|size_type size() const
| { return
> Yes, but too often this is not one-liners, but two-liners on one line:
>
> size_type size() const { Assert(...); return data_.size(); }
Those are gone now, aren't they? ;-)
Ok, I admit, my personal limit in such cases is about four lines, i.e.
usually one or two initializations, and
Doing lyx -x lyx-quit big.lyx, the attached patch
gives the following results (warm cache, error around 4%) :
user (s)| sys (s) | elapsed (s) |
--
28.33 (0.00%) | 0.30 (0.00%) | 29.61 (0.00%)
John Levon [EMAIL PROTECTED] writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
| --
| 28.33
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
|
John Levon [EMAIL PROTECTED] writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
| --
| 28.33
On Thu, 15 Mar 2001, John Levon wrote:
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
|
John Levon [EMAIL PROTECTED] writes:
| hum, now I'm really confused :
|
| pg008:1050 size lyx
|textdata bss dec hex filename
| 2643515 19332 43100 2705947 294a1b lyx
| pg008:1051 size lyxnew
|textdata bss dec hex filename
| 2638043 19332 43100
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| hum, now I'm really confused :
|
| pg008:1050 size lyx
|textdata bss dec hex filename
| 2643515 19332 43100 2705947 294a1b lyx
| pg008:1051 size lyxnew
|textdata bss
John Levon [EMAIL PROTECTED] writes:
| and widh_this.size() is inlined and do_something segfaults, the
| segfault can look like it happened inside with_this.size().
|
| and this is reason enough to not have this speedup ??
Yes, I belive a more detrministic development environment is reason
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| and widh_this.size() is inlined and do_something segfaults, the
| segfault can look like it happened inside with_this.size().
|
| and this is reason enough to not have this speedup ??
Yes, I belive a
John Levon [EMAIL PROTECTED] writes:
| I mean there will be one in foo.C AND non-inlined copies in anything including
|foo.h.
| Or am I talking crap again
foo_inlines.h should only be included in foo.h if
INLINE_SIMPLE_METHODS is defined.
Lgb
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
foo_inlines.h should only be included in foo.h if
INLINE_SIMPLE_METHODS is defined.
Lgb
*sigh*
I really do have problems with reading :P
john
--
"24-hour boredom
I'm convicted instantly"
- Manic Street Preachers
On 15-Mar-2001 John Levon wrote:
I really do think the speedup is significant enough to live with the debugging
problem...
What debugging problem? I compile with only -g option and then inlined code
is no problem on debugging!
Jrgen
--
Juergen Vigna [EMAIL PROTECTED] writes:
| On 15-Mar-2001 John Levon wrote:
|
| I really do think the speedup is significant enough to live with the debugging
| problem...
|
| What debugging problem? I compile with only -g option and then inlined code
| is no problem on debugging!
Well I
On 15 Mar 2001, Lars Gullik Bjnnes wrote:
[How to avoid inlining to improve debugging]
Well I consider compiling without -O an even bigger problem. Then a lot
of small problems will not be noticed until you compile with
optimization turned on.
Are you sure that there is not a flag to gcc
Are you sure that there is not a flag to gcc such that you can compile
with -O, but without inlining?
-fno-inline would sound appropriate, wouldn't it?
[...]
The code is often easier to understand when the definition is close to the
declaration for these bits of code that are really
Doing lyx -x lyx-quit big.lyx, the attached patch
gives the following results (warm cache, error around 4%) :
user (s)| sys (s) | elapsed (s) |
--
28.33 (0.00%) | 0.30 (0.00%) | 29.61 (0.00%)
John Levon <[EMAIL PROTECTED]> writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
| --
|
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | Doing lyx -x lyx-quit big.lyx, the attached patch
> | gives the following results (warm cache, error around 4%) :
> |
> | user (s)| sys (s) | elapsed (s) |
> |
John Levon <[EMAIL PROTECTED]> writes:
| Doing lyx -x lyx-quit big.lyx, the attached patch
| gives the following results (warm cache, error around 4%) :
|
| user (s)| sys (s) | elapsed (s) |
| --
|
On Thu, 15 Mar 2001, John Levon wrote:
> On 15 Mar 2001, Lars Gullik Bjønnes wrote:
>
> > John Levon <[EMAIL PROTECTED]> writes:
> >
> > | Doing lyx -x lyx-quit big.lyx, the attached patch
> > | gives the following results (warm cache, error around 4%) :
> > |
> > | user (s)| sys (s)
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | Doing lyx -x lyx-quit big.lyx, the attached patch
> | gives the following results (warm cache, error around 4%) :
> |
> | user (s)| sys (s) | elapsed (s) |
> |
John Levon <[EMAIL PROTECTED]> writes:
| hum, now I'm really confused :
|
| pg008:1050 size lyx
|textdata bss dec hex filename
| 2643515 19332 43100 2705947 294a1b lyx
| pg008:1051 size lyxnew
|textdata bss dec hex filename
| 2638043 19332 43100
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | hum, now I'm really confused :
> |
> | pg008:1050 size lyx
> |textdata bss dec hex filename
> | 2643515 19332 43100 2705947 294a1b lyx
> | pg008:1051 size lyxnew
> |text
John Levon <[EMAIL PROTECTED]> writes:
| > and widh_this.size() is inlined and do_something segfaults, the
| > segfault can look like it happened inside with_this.size().
|
| and this is reason enough to not have this speedup ??
Yes, I belive a more detrministic development environment is
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | > and widh_this.size() is inlined and do_something segfaults, the
> | > segfault can look like it happened inside with_this.size().
> |
> | and this is reason enough to not have this speedup ??
>
> Yes,
John Levon <[EMAIL PROTECTED]> writes:
| I mean there will be one in foo.C AND non-inlined copies in anything including
|foo.h.
| Or am I talking crap again
foo_inlines.h should only be included in foo.h if
INLINE_SIMPLE_METHODS is defined.
Lgb
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
> foo_inlines.h should only be included in foo.h if
> INLINE_SIMPLE_METHODS is defined.
>
> Lgb
*sigh*
I really do have problems with reading :P
john
--
"24-hour boredom
I'm convicted instantly"
- Manic Street Preachers
On 15-Mar-2001 John Levon wrote:
> I really do think the speedup is significant enough to live with the debugging
> problem...
What debugging problem? I compile with only -g option and then inlined code
is no problem on debugging!
Jürgen
--
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 15-Mar-2001 John Levon wrote:
|
| > I really do think the speedup is significant enough to live with the debugging
| > problem...
|
| What debugging problem? I compile with only -g option and then inlined code
| is no problem on debugging!
Well I
On 15 Mar 2001, Lars Gullik Bjønnes wrote:
[How to avoid inlining to improve debugging]
> Well I consider compiling without -O an even bigger problem. Then a lot
> of small problems will not be noticed until you compile with
> optimization turned on.
Are you sure that there is not a flag to gcc
> Are you sure that there is not a flag to gcc such that you can compile
> with -O, but without inlining?
-fno-inline would sound appropriate, wouldn't it?
> [...]
> The code is often easier to understand when the definition is close to the
> declaration for these bits of code that are really
36 matches
Mail list logo
