On Jun 2 15:00, Christopher Faylor wrote:
You could do things the other way around, so that NtCreateFile is used
in the main code which invokes a NtCreateFile wrapper for 9x systems but
I am leery of doing things this way since that means that the only
people capable of writing code for
Christopher Faylor wrote:
Keith, you don't have a complete reference for the Nt functions do you?
For the most part, using the APIs is pretty straight-forward if you have
the required prototypes and structure definitions. With the possible
exception of NtCreateProcess(), there is not a lot of
Original Message
From: Keith Moore
Sent: 03 June 2005 11:05
Christopher Faylor wrote:
Keith, you don't have a complete reference for the Nt functions do you?
For the most part, using the APIs is pretty straight-forward if you have
the required prototypes and structure definitions.
On Fri, Jun 03, 2005 at 12:05:28PM +0200, Keith Moore wrote:
Christopher Faylor wrote:
Keith, you don't have a complete reference for the Nt functions do you?
For the most part, using the APIs is pretty straight-forward if you have
the required prototypes and structure definitions. With the
Christopher Faylor wrote:
Keith, you don't have a complete reference for the Nt functions do
you?
Keith Moore wrote:
So, unfortunately, I don't have a complete reference, but there are
enough islands of information around for us to piece together
everything we need.
Have you looked at
One area that I've noticed slowness is in using the 'find' command
to search for old tmp files or to rebuild the locate database.
In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed. One way to speed up
operations in this area might
Hi,
here's a little study, allocating / freeing mem in a loop, once with the
C malloc/free, once (-DUSE_CXX_HEAP) using new/delete. It reproduces the
factor ~3 for gcc cygwin.
I've built it with MSVC's cl 7.0, gcc 3.3.3, with and without
-mno-cygwin, using the cygwin-inst snapshot from 20050528,
amusingling enough -- their
execution times are *slower* than cygwin's... Of
this is a joke right? I found SFU to be at least 2-3
times faster in loading and executing programs in
general. Its too bad their POSIX imple. is less than
half baked and unuseable for building any package
OOTB.
On Thu, 2 Jun 2005, Linda W wrote:
In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed. One way to speed up
operations in this area might be to keep a cache of the last N
file handles. I suspect it's just the Windows path lookup
On Thu, 2 Jun 2005, Sunil wrote:
amusingling enough -- their
execution times are *slower* than cygwin's... Of
this is a joke right? I found SFU to be at least 2-3
times faster in loading and executing programs in
general. Its too bad their POSIX imple. is less than
half baked and
Original Message
From: Igor Pechtchanski
Sent: 02 June 2005 18:08
On Thu, 2 Jun 2005, Sunil wrote:
amusingling enough -- their
execution times are *slower* than cygwin's... Of
this is a joke right? I found SFU to be at least 2-3
times faster in loading and executing programs in
On Thu, Jun 02, 2005 at 01:02:30PM -0400, Igor Pechtchanski wrote:
On Thu, 2 Jun 2005, Linda W wrote:
In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed. One way to speed up
operations in this area might be to keep a cache of the last
Any favorable mention of SFU on this list had better
be a joke. :-)
:)
but can't deny the truth. Seriously, open source on
windows can't do better than what it does(upto the
limits provided by OS) in terms of efficiency. Its
hardly at fault, the thing below it is so darn closed.
Everything on
On Thu, 2 Jun 2005, Sunil wrote:
Any favorable mention of SFU on this list had better
be a joke. :-)
:)
but can't deny the truth. Seriously, open source on
windows can't do better than what it does(upto the
limits provided by OS) in terms of efficiency. Its
hardly at fault, the thing
On Thu, Jun 02, 2005 at 11:04:40AM -0700, Sunil wrote:
Any favorable mention of SFU on this list had better be a joke. :-)
:)
but can't deny the truth. Seriously, open source on windows can't do
better than what it does(upto the limits provided by OS) in terms of
efficiency. Its hardly at
OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
if it wasn't for the requirement that everything has to work
on Windows
9x, the DLL would be smaller and faster. Instead, every system call
currently needs to have a do this if it's NT and that if
it's 9x test
so we
On Thu, 2 Jun 2005, Robb, Sam wrote:
OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
if it wasn't for the requirement that everything has to work on
Windows 9x, the DLL would be smaller and faster. Instead, every
system call currently needs to have a do this if
Sunil wrote:
machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, - build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, - build time for texinfo =
334 seconds.
- 345 seconds vs. 334 seconds
So actually, cygwin is faster
On Thu, Jun 02, 2005 at 02:38:06PM -0400, Robb, Sam wrote:
OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
if it wasn't for the requirement that everything has to work on Windows
9x, the DLL would be smaller and faster. Instead, every system call
currently needs to have a
Gerrit P. Haase wrote:
Sunil wrote:
machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, - build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, - build time for texinfo =
334 seconds.
- 345 seconds vs. 334 seconds
Igor Pechtchanski wrote:
On Thu, 2 Jun 2005, Robb, Sam wrote:
Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?
Aside from potential installation issues (install this
version of the DLL under 9x, that version under NT), it
seems
On Thu, 2 Jun 2005, Gerrit P. Haase wrote:
Igor Pechtchanski wrote:
On Thu, 2 Jun 2005, Robb, Sam wrote:
Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?
Aside from potential installation issues (install this
Igor Pechtchanski wrote:
Dropping it altogether would be unfortunate. Providing Win98 support DLLs
in a separate package is a possibility. There's still the point that CGF
raised, about there being many more people with the knowledge of Win32 API
than those with the knowledge of Nt* API.
Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
Igor Pechtchanski wrote:
Dropping it altogether would be unfortunate. Providing Win98 support DLLs
in a separate package is a possibility. There's still the point that CGF
raised, about there being many more people with the
Might it be possible to build 2 versions and have the package
dynamically install the correct version?
On the other hand, instead of if (win98)... one could have a
cygwin1.dll that chooses a 2nd library to load and all entry points are
either runtime indirect calls into the 2nd library
On Thu, Jun 02, 2005 at 11:57:26PM +0200, Ralf Habacker wrote:
Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
Igor Pechtchanski wrote:
Dropping it altogether would be unfortunate. Providing Win98 support
DLLs in a separate package is a possibility. There's still the point
that CGF
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor
Sent: Saturday, May 28, 2005 12:46 PM
To: cygwin@cygwin.com
Subject: Re: Serious performance problems (malloc related?)
On Sat, May 28, 2005 at 10:19:26AM -0700, Andy Ross wrote
On Mon, May 30, 2005 at 10:15:56PM -0500, Gary R. Van Sickle wrote:
Can we get a gold star here for Chris' first-ever apology for his
anti-social behavior?
Once again, my reply will be in cygwin-talk.
Gary, I will once again (is this the third time now?) direct you there.
FYI, I won't keep
On Fri, May 27, 2005 at 09:54:28PM -0700, Andy Ross wrote:
Christopher Faylor wrote:
Gee, I'm sorry you thought I was being snippy. You apparently missed
that I was just providing you with some obvious advice.
Indeed. To paraphrase: Fix it yourself, not my problem.
Actually, I think I implied
I have similar problem with CPU bound program of mine on Cygwin too. The
difference is something like 35 minutes versus 400 seconds on the same machine
but under FreeBSD.
Somebody mentioned that malloc implementation could be the problem. Dunno. I
has also crossed my mind that another difference
On Sat, May 28, 2005 at 01:24:31PM +0200, Vaclav Haisman wrote:
I have similar problem with CPU bound program of mine on Cygwin too.
The difference is something like 35 minutes versus 400 seconds on the
same machine but under FreeBSD.
Yep. This is pretty much what I expected. Now we'll see a
On Sat, May 28, 2005 at 07:24:25AM -0700, Andy Ross wrote:
I won't have a win32 box available to test with until after the
weekend, though. I know you'd prefer that I spend my own time working
on this, but like I said this really isn't my platform. I got involved
trying to help out FlightGear
[Last post. I've done my time in windows, and am going back to a
world where the software works and people are helpful.]
Christopher Faylor wrote:
I don't think there is much to be gained by reiterating that you have a
large user base who is impacted by this. We're not a technical support
On Sat, May 28, 2005 at 10:19:26AM -0700, Andy Ross wrote:
[Last post. I've done my time in windows, and am going back to a
world where the software works and people are helpful.]
Christopher Faylor wrote:
I don't think there is much to be gained by reiterating that you have a
large user base
Andy Ross wrote:
But as I noted in my original post: It's not waiting on the disk
reads. Comment out the split() call and watch the delays disappear.
Raw I/O speed in cygwin is comparable to mingw or MSVC. The overhead
is due, somehow, to activity within/under split(). Other than
allocation,
On Sat, 28 May 2005, Gerrit P. Haase wrote:
Andy Ross wrote:
But as I noted in my original post: It's not waiting on the disk
reads. Comment out the split() call and watch the delays disappear.
Raw I/O speed in cygwin is comparable to mingw or MSVC. The overhead
is due, somehow, to
On Sat, May 28, 2005 at 10:51:01PM +0200, Vaclav Haisman wrote:
On Sat, 28 May 2005, Gerrit P. Haase wrote:
Andy Ross wrote:
But as I noted in my original post: It's not waiting on the disk
reads. Comment out the split() call and watch the delays disappear.
Raw I/O speed in cygwin is
Vaclav Haisman wrote:
On Sat, 28 May 2005, Gerrit P. Haase wrote:
Andy Ross wrote:
But as I noted in my original post: It's not waiting on the disk
reads. Comment out the split() call and watch the delays disappear.
Raw I/O speed in cygwin is comparable to mingw or MSVC. The overhead
is
At FlightGear, we have a bunch of users building on Cygwin as their
environment (MSVC and mingw builds are possible but non-trivial, and
the configure scripts work out-of-the-box on cygwin) and complaints of
performance problems have been persistent. When it was recently
pointed out that the
On Fri, May 27, 2005 at 03:38:03PM -0700, Andy Ross wrote:
At FlightGear, we have a bunch of users building on Cygwin as their
environment (MSVC and mingw builds are possible but non-trivial, and
the configure scripts work out-of-the-box on cygwin) and complaints of
performance problems have been
Christopher Faylor quipped:
It seems pretty clear to me that if this is a really serious problem
for you then the best way to get it fixed is to gain more than zero
knowledge of cygwin.
Gee, thanks. Very helpful. Can you at least type the commands in and
verify the problem for me before you
On Fri, May 27, 2005 at 05:04:02PM -0700, Andy Ross wrote:
Christopher Faylor quipped:
It seems pretty clear to me that if this is a really serious problem
for you then the best way to get it fixed is to gain more than zero
knowledge of cygwin.
Gee, thanks. Very helpful. Can you at least
On Fri, May 27, 2005 at 08:50:54PM -0400, Christopher Faylor wrote:
On Fri, May 27, 2005 at 05:04:02PM -0700, Andy Ross wrote:
Christopher Faylor quipped:
It seems pretty clear to me that if this is a really serious problem
for you then the best way to get it fixed is to gain more than zero
Christopher Faylor wrote:
Gee, I'm sorry you thought I was being snippy. You apparently
missed that I was just providing you with some obvious advice.
Indeed. To paraphrase: Fix it yourself, not my problem.
It seems like if this was a really serious problem you'd be actively
working
On Fri, May 27, 2005 at 09:29:54PM -0700, Edward Peschko wrote:
But Mr. Faylor, no offense, but you *are* snippy.
I think we've recently demonstrated that this type of discussion is
not appreciated in the main cygwin list so my response to this message
will be in cygwin-talk.
Please redirect all
45 matches
Mail list logo
