Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
Date: Mon, 12 Nov 2007 07:18:23 +0100	[thread overview]
Message-ID: <1194848303.4737f02f985a5@webmail.in-berlin.de> (raw)
In-Reply-To: <20071111204019.4697d387@localhost.localdomain>

Zitat von Fabrice Marchant <fabrice.marchant@orange.fr>:

>   Hi Oliver !
>
>  Thanks to have considered my problem.
>
> On Sun, 11 Nov 2007 17:48:34 +0100
> Oliver Bandel <oliver@first.in-berlin.de> wrote:
>
> >
>
http://caml.inria.fr/pub/ml-archives/caml-list/2002/09/d29ca3379fe68e3cdbd36323f5f409c0.en.html
>
> > This code looks ugly.
> ...
> > It forces calls to the scheduler all too often.
> > And it does it at three places. And in the print-loop
> > it clals it every time!
> > This is the way of wasting ressources.
>   I think these 'yields' are only desperate attempts to hint the scheduler to
> do its job - that it doesn't as we could expected -.
[...]

Yes, that also was my view on using this function to often.

It's like using OCaml: ehy to use the GC-Module?
I have not used it, because I didn't needed.
I first look, if my code could possibly done better,
instead of thinking the gaerbageCollector might do something wrong.

The Gc-module is there to have a possibility to use some
screws for manual fine-tuning. But you should not start to
use it until your application seems to be ready.

It's like in LaTeX, where you should not too often
look at the results of line braking. You can do fine tuning
at the end.

And Gc or in Threading: explicit hints to the scheduler
should be used, if necessary, and not as early as possible.

But these are very general hints: optimization of details
comes at the end.

Best way to avoid "problems that have to be fixed by hand later"
(workarounds) is, to have some consideration on the design when
you start (and during the whole development phase of course).

(In LaTeX: use the pramble for selecting the right class and packages
and do not insert paragraph spacing throughout the whole document, if you
can change \parskip and \parindent ;-))


Ciao,
   Oliver

P.S.: And looking for Bugfixes in the libraries (as the one with the
      example code of "toto.ml") is the thing that comes in the very end,
      when the code is really good. If someone writes bad code and then
      looking for bugfixes of the langaueg he/she uses, that's a littlebid
      strange, IMHO.
      For concurrent programming you need to rethink many things, compared to
      non-concurrent programming. It's a littlebid like switching to FP,
      coming from non-FP-languages.


      parent reply	other threads:[~2007-11-12  6:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10 22:01 Fabrice Marchant
2007-11-11 14:07 ` [Caml-list] " Fabrice Marchant
2007-11-11 16:48   ` Oliver Bandel
2007-11-11 18:35     ` Julien Moutinho
2007-11-11 20:13       ` Fabrice Marchant
2007-11-12  0:33       ` Oliver Bandel
2007-11-11 19:40     ` Fabrice Marchant
2007-11-12  0:43       ` Oliver Bandel
2007-11-12 19:54         ` Fabrice Marchant
2007-11-12 21:18           ` Oliver Bandel
2007-11-13  7:45             ` Fabrice Marchant
2007-11-13 10:14               ` Oliver Bandel
2007-11-13 20:10                 ` Fabrice Marchant
2007-11-14  0:33                   ` Oliver Bandel
2007-11-12  0:46       ` Oliver Bandel
2007-11-12  6:18       ` Oliver Bandel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1194848303.4737f02f985a5@webmail.in-berlin.de \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox