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

Groups > comp.sys.acorn.programmer > #6105 > unrolled thread

case sensitive file test

Back to article view | Back to comp.sys.acorn.programmer

Contents

  case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 12:46 +0100
    Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 14:21 +0100
      Re: case sensitive file test Kevin Wells <kev@kevsoft.co.uk> - 2020-05-26 15:34 +0100
        Re: case sensitive file test Steve Fryatt <news@stevefryatt.org.uk> - 2020-05-26 17:12 +0100
          Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 17:42 +0100
            Re: case sensitive file test Steve Fryatt <news@stevefryatt.org.uk> - 2020-05-26 18:21 +0100
              Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 19:46 +0100
          Re: case sensitive file test Steve Drain <steve@kappa.me.uk> - 2020-05-27 13:14 +0100
            Re: case sensitive file test jgh@mdfs.net - 2020-05-27 16:25 -0700
              Re: case sensitive file test Steve Drain <steve@kappa.me.uk> - 2020-05-28 14:16 +0100
                Re: case sensitive file test druck <news@druck.org.uk> - 2020-06-01 20:01 +0100
        Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 17:29 +0100
          Re: case sensitive file test Steve Fryatt <news@stevefryatt.org.uk> - 2020-05-26 17:52 +0100
            Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 18:06 +0100
          Re: case sensitive file test "John Williams (News)" <UCEbin@tiscali.co.uk> - 2020-05-26 18:00 +0100
            Re: case sensitive file test "John Williams (News)" <UCEbin@tiscali.co.uk> - 2020-05-26 18:07 +0100
            Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 19:40 +0100
      Re: case sensitive file test David Higton <dave@davehigton.me.uk> - 2020-05-26 18:08 +0100
        Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-05-26 19:40 +0100
    Re: case sensitive file test Erik G <noreply123@xs4all.nl> - 2020-06-01 03:19 +0200
      Re: case sensitive file test Bob Latham <bob@sick-of-spam.invalid> - 2020-06-01 15:53 +0100
      Re: case sensitive file test druck <news@druck.org.uk> - 2020-06-01 20:57 +0100
      Re: case sensitive file test jgh@mdfs.net - 2020-06-04 09:23 -0700
        Re: case sensitive file test Martin <News03@avisoft.f9.co.uk> - 2020-06-04 17:51 +0100
        Re: case sensitive file test druck <news@druck.org.uk> - 2020-06-04 20:49 +0100
          Re: case sensitive file test jgh@mdfs.net - 2020-06-04 16:18 -0700
            Re: case sensitive file test druck <news@druck.org.uk> - 2020-06-05 11:27 +0100

Page 2 of 2 — ← Prev page 1 [2]

#6124

In article <5ed457bc$0$1436$e4fe514c@newszilla.xs4all.nl>,
   Erik G <noreply123@xs4all.nl> wrote:

> And finally: developers of filing systems have worked for decades
> to optimise the finding, reading, writing, extending and deletion
> of files, using every trick in the book and inventing new ones,
> because disk I/O is one of the major bottlenecks in the speed at
> which programs run.

Thank you for an interesting read.

In my case I'm checking for various things in a music library stored
on a Synology DS214+. My program written in assembler, uses Lanman98
to access the NAS which was quite a bit faster than moonfish.

The program examines every album and checks for images, file types,
and tags. On flac albums (all 3390 of them), for every track on every
album the file is opened and the tagging checked and then the file is
closed again.

The program then gives a report on any none conformity to various
parameters set.

It varies slightly from run to run but it takes about 14 minutes and
20 seconds to complete. I'm impressed with the speed.

Thanks again.

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

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

#6126

On 01/06/2020 02:19, Erik G wrote:
> And finally: developers of filing systems have worked for decades to
> optimise the finding, reading, writing, extending and deletion of files,
> using every trick in the book and inventing new ones, because disk I/O
> is one of the major bottlenecks in the speed at which programs run.

Unfortunately except on RISC OS, where no use is made of free memory to 
cache filing system operations, as just about every other common OS does.

The closest RISC OS comes is some fixed size buffering an ADFS, which 
often resulted in the Risc PC's slow motherboard IDE interface 
outperforming much better 3rd party IDE hardware using IDEFS variants 
with no caching.

---druck

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

#6127

Similarly, if there's some I/O information that won't change over the
run of a program, read it once into a variable, then access the variable.
For example:
 size%=EXT#inputfile then use size% instead of EXT#
If your program is never going to change screen mode:
 SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%

etc.

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

#6128

On 04 Jun in article
<a248d019-7c38-439a-8d5f-62d6d817a285@googlegroups.com>,
   <jgh@mdfs.net> wrote:
> Similarly, if there's some I/O information that won't change over
> the run of a program, read it once into a variable, then access the
> variable.

> For example:
>  size%=EXT#inputfile then use size% instead of EXT#

Excellent advice, in general ... but this example ...

> If your program is never going to change screen mode:
>  SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%

is a bad one, because if it is a Wimp program the mode is usually
changed outside your program, so ModeChange messages have to be
watched for and the relevant variables read again.

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

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

#6129

On 04/06/2020 17:23, jgh@mdfs.net wrote:
> Similarly, if there's some I/O information that won't change over the
> run of a program, read it once into a variable, then access the variable.
> For example: >   size%=EXT#inputfile then use size% instead of EXT#

Sorry, that's bad advice, a program should always assume filing system 
data may be altered by other processes.

1) Obviously if its a Wimp application, other tasks are running
2) If the single tasking program can be run a in taskwindow or graphic
    taskwindow, other tasks are running
3) If the file is on a remote filing system, other machines may alter it
4) If the file is on a local filing system which is shared, other
    machines may alter it.

So only if you are outside the desktop, and storage is on a local non 
shared disc, can you be sure it wont be altered by anything else.

> If your program is never going to change screen mode:
>   SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%

Only if its running outside the desktop. Inside the desktop the mode can 
change, so you need to ensure you handle the mode change message an 
re-read any mode related parameters you are using.

---druck

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

#6130

On Thursday, 4 June 2020 20:49:57 UTC+1, druck  wrote:
> > For example: size%=EXT#inputfile then use size% instead of EXT#
> 
> Sorry, that's bad advice, a program should always assume filing system 
> data may be altered by other processes.

If it's open for input, other processes *can't* alter it.
Read By Many, Write By One.

> > If your program is never going to change screen mode:
> >   SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%
> 
> Only if its running outside the desktop. Inside the desktop the mode can 
> change, so you need to ensure you handle the mode change message an 
> re-read any mode related parameters you are using.

Which is why I wrote 'your program is never going to change screen
mode'. Maybe it should have been 'where the screen mode is never
going to be changed during the execution of the program'. Such as
a command line tool or a single-taking application.

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

#6131

On 05/06/2020 00:18, jgh@mdfs.net wrote:
> On Thursday, 4 June 2020 20:49:57 UTC+1, druck  wrote:
>>> For example: size%=EXT#inputfile then use size% instead of EXT#
>>
>> Sorry, that's bad advice, a program should always assume filing system
>> data may be altered by other processes.
> 
> If it's open for input, other processes *can't* alter it.
> Read By Many, Write By One.

It's down to the implementation of the filing system to whether that is 
true. Local filing systems will tend to lock on write, remote ones will 
tend not to. It's a bit of a mine field!

---druck

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web