Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25534 > unrolled thread

Re: replace extended characters

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: replace extended characters Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-11 13:06 +1300
    Re: replace extended characters Arne Vajhøj <arne@vajhoej.dk> - 2011-02-10 21:45 -0500
    Re: replace extended characters Lew <noone@lewscanon.com> - 2011-02-11 17:39 -0500
    Re: replace extended characters Paul Cager <paul.cager@googlemail.com> - 2011-02-11 09:18 -0800
    Re: replace extended characters Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-02-10 21:27 -0400
      Re: replace extended characters Arne Vajhøj <arne@vajhoej.dk> - 2011-02-10 21:42 -0500
      Re: replace extended characters Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-11 15:35 +1300
      Re: replace extended characters Lew <noone@lewscanon.com> - 2011-02-10 21:29 -0500

#25534 — Re: replace extended characters

In message
<15bd3363-c781-487b-98d5-2243eff7cc8f@24g2000yqa.googlegroups.com>, VIDEO 
MAN wrote:

> How would people suggest I approach this from an efficiency  point of
> view given that the input files could be pretty large?

Correctness comes before efficiency. Get it working first.

[toc] | [next] | [standalone]

#25561

On 10-02-2011 20:27, Arved Sandstrom wrote:
> On 11-02-10 08:06 PM, Lawrence D'Oliveiro wrote:
>> In message
>> <15bd3363-c781-487b-98d5-2243eff7cc8f@24g2000yqa.googlegroups.com>, VIDEO
>> MAN wrote:
>>> How would people suggest I approach this from an efficiency point of
>>> view given that the input files could be pretty large?
>>
>> Correctness comes before efficiency. Get it working first.
>
> That's actually not true. When you're designing your solution - which is
> the point that the OP is at - you should most definitely be considering
> efficiency. More often than not you cannot make an inefficient solution
> efficient without changing it fairly radically, so why not design it
> properly first?
>
> It's much more correct to say, get an efficient maintainable solution
> working correctly first, then do your last little tweaks if necessary.

Yep.

Clean code with good big O characteristics and then measure
and evaluate whether further optimization is necessary.

Arne

[toc] | [prev] | [next] | [standalone]

#25562

Arne Vajhøj wrote:
>> Good design is not premature optimization.

Paul Cager wrote:
> That's true, but in this case I'd like to quote Rob Pike: "Bottlenecks
> occur in surprising places, so don't try to second guess and put in a
> speed hack until you have proven that's where the bottleneck is."
>
> Where would you guess the program will be spending most of its time -
> manipulating bits in the CPU or waiting for disk IO?

It's too early to ask that question.  It suffices to come up with the 
reasonably performant algorithm as suggested upthread.  No one so far has 
engaged in premature optimization here.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [next] | [standalone]

#25663

On Feb 11, 2:42 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 10-02-2011 21:35, Lawrence D'Oliveiro wrote:
> > In message<pg05p.441$Y63...@newsfe02.iad>, Arved Sandstrom wrote:
> >> On 11-02-10 08:06 PM, Lawrence D'Oliveiro wrote:
> >>> In message
> >>> <15bd3363-c781-487b-98d5-2243eff7c...@24g2000yqa.googlegroups.com>, VIDEO
> >>> MAN wrote:
> >>>> How would people suggest I approach this from an efficiency  point of
> >>>> view given that the input files could be pretty large?
>
> >>> Correctness comes before efficiency. Get it working first.
>
> >> That's actually not true. When you're designing your solution - which is
> >> the point that the OP is at - you should most definitely be considering
> >> efficiency.
>
> > It was either Donald Knuth or Tony Hoare who said “premature optimization is
> > the root of all evil”. You can’t worry about efficiency until you know where
> > your inefficiencies are.
>
> Good design is not premature optimization.

That's true, but in this case I'd like to quote Rob Pike: "Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you have proven that's where the bottleneck is."

Where would you guess the program will be spending most of its time -
manipulating bits in the CPU or waiting for disk IO?

[toc] | [prev] | [next] | [standalone]

#25804

On 11-02-10 08:06 PM, Lawrence D'Oliveiro wrote:
> In message
> <15bd3363-c781-487b-98d5-2243eff7cc8f@24g2000yqa.googlegroups.com>, VIDEO
> MAN wrote:
>
>> How would people suggest I approach this from an efficiency  point of
>> view given that the input files could be pretty large?
>
> Correctness comes before efficiency. Get it working first.

That's actually not true. When you're designing your solution - which is 
the point that the OP is at - you should most definitely be considering 
efficiency. More often than not you cannot make an inefficient solution 
efficient without changing it fairly radically, so why not design it 
properly first?

It's much more correct to say, get an efficient maintainable solution 
working correctly first, then do your last little tweaks if necessary.

AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

[toc] | [prev] | [next] | [standalone]

#25969

On 10-02-2011 21:35, Lawrence D'Oliveiro wrote:
> In message<pg05p.441$Y63.22@newsfe02.iad>, Arved Sandstrom wrote:
>> On 11-02-10 08:06 PM, Lawrence D'Oliveiro wrote:
>>> In message
>>> <15bd3363-c781-487b-98d5-2243eff7cc8f@24g2000yqa.googlegroups.com>, VIDEO
>>> MAN wrote:
>>>> How would people suggest I approach this from an efficiency  point of
>>>> view given that the input files could be pretty large?
>>>
>>> Correctness comes before efficiency. Get it working first.
>>
>> That's actually not true. When you're designing your solution - which is
>> the point that the OP is at - you should most definitely be considering
>> efficiency.
>
> It was either Donald Knuth or Tony Hoare who said “premature optimization is
> the root of all evil”. You can’t worry about efficiency until you know where
> your inefficiencies are.

Good design is not premature optimization.

Arne

[toc] | [prev] | [next] | [standalone]

#25993

In message <pg05p.441$Y63.22@newsfe02.iad>, Arved Sandstrom wrote:

> On 11-02-10 08:06 PM, Lawrence D'Oliveiro wrote:
>
>> In message
>> <15bd3363-c781-487b-98d5-2243eff7cc8f@24g2000yqa.googlegroups.com>, VIDEO
>> MAN wrote:
>>
>>> How would people suggest I approach this from an efficiency  point of
>>> view given that the input files could be pretty large?
>>
>> Correctness comes before efficiency. Get it working first.
> 
> That's actually not true. When you're designing your solution - which is
> the point that the OP is at - you should most definitely be considering
> efficiency.

It was either Donald Knuth or Tony Hoare who said “premature optimization is 
the root of all evil”. You can’t worry about efficiency until you know where 
your inefficiencies are.

[toc] | [prev] | [next] | [standalone]

#26083

Arved Sandstrom wrote:
> That's actually not true. When you're designing your solution - which is the
> point that the OP is at - you should most definitely be considering
> efficiency. More often than not you cannot make an inefficient solution
> efficient without changing it fairly radically, so why not design it properly
> first?
>
> It's much more correct to say, get an efficient maintainable solution working
> correctly first, then do your last little tweaks if necessary.

The OP correctly seeks to consider algorithms prior to delving into 
implementation.  Arved wisely shows how correctness and algorithmic efficiency 
can share precedence.  Joshua reminds us that problem scale affects 
performance analysis and design.

Optimizations discussed here so far have avoided descent into 
micro-optimization, and we have heard a helpful caution against such error. 
The OP's goal lets us clarify the difference.

Synthesizing the advice of our gurus, the OP now knows that a couple of 
algorithms - character-at-a-time and block-oriented - will work, and at what 
problem scales they're likely to help.  (Predictions prior to measurement are 
always at best hypothetical, but you have to assess likelihood while 
planning.)  Signposts guard the fringes - avoid multi-char code points and 
large character sets.  Those are the optimizations and the correctness. 
Performance analysis is algorithmic and doesn't seem premature.

Micro-optimization would be to start in right away with custom char arrays and 
manual buffering through idiosyncratic I/O streams.  Whatever the standard API 
may lack, it at least provides decent infrastructure for that sort of thing. 
So initial implementation will leave that stuff bog standard, and I'll bet 
dollars to doughnuts that in the OP's scenario that'll do.  Changing that 
layer from get-go would be tweaking and constitutes premature optimization, 
a.k.a. micro-optimization.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web