Re: Is it a bug in Gio::FileMonitor?

[Владимир <cl333r gmail com>]

Hi,

I agree with you, it's not feasible to talk in terms of good or bad, the whole picture is bigger than that.
I'm just saying that I'd like to use gio because I'm using gtkmm and it has a built-in backend to it, while inotify doesn't, so I'm frustrated
that to keep my app quick I have to go to inotify (my app only needs Linux so compatibility is not an issue) so if the gio devs think it's not an issue or can't be fixed I respect that
and I'm just going to another solution.

But I'd also like to mention (if anyone cares) that the next Java version (JDK7) which is due to be released allegedly this autumn features a new I/O (NIO2)
and I used it and its new file monitoring capabilities are like those of inotify, that is, they're also quick at reporting even 1-file-changes, I used it in another app (I'm actually more of a Java dev) and I had no problems with it,
and Java is also cross platform so I think that saying or implying that gio is slow on this particular issue due to having to be cross-platform looks like an excuse to me to not try to make it
better, but again, I hope people don't think I'm being harsh by providing examples because I want it to be quick like the other alternatives, but looks like there's no hope to fix it and/or that I'm the only one being interested into this issue (or acknowledging that it's an issue in the first place).

On a (somewhat completely) different issue, I found it slightly disturbing that there's no good/qualitative examples of using gio, in particular to list files in a dir. When I googled (for giomm examples) I found
a link to
http://svn.gnome.org/viewvc/gtkmm-documentation/trunk/examples/book/giomm/
which is very slow to list larger dirs (like /usr/lib or /usr/bin), using that example will take like 4-10 seconds to list all files (which get cached probably by gtkmm hence listing those dirs second time is faster but still not a good solution,
btw Java or the plain C++ lib does that in about 1 second or less without the need to cache them first) so it's another "be slow by default for a noble excuse" attitude which I found in gio and I think it's slightly disturbing. Is it so unimportant to be snappy nowadays that we have to publish such slow solutions and not even mention it?

On Wed, Jun 2, 2010 at 1:34 PM, Sven Herzberg <herzi gnome-de org> wrote:

Hi,

Am Mittwoch, den 02.06.2010, 04:26 +0300 schrieb Владимир:

>

For one thing: Please don't try to tell people that inotify is better
than GIO. GIO can use inotify as a backend [1] on GNU/Linux and _has_ to
use other backends on other platforms (just like Alex already
mentioned).

For the other: try to run something like this in several processes
(10-20) in parallel on your downloaded file (preferably on a tmpfs to
make sure the hard drive won't end up being the bottleneck at some
point):
$ split --bytes=4 $YOUR_DOWNLOADED_FILE
inotify should pretty quickly make your monitoring application cough up.

[1]http://git.gnome.org/browse/glib/tree/configure.in#n1626

Regards,
 Sven