> MacBook Mac OS X 10.5.8
> 2 GHz Intel Core Duo
> 1 GB memory:
> 17 minutes 46 seconds.
>
> IBM ThinkPad
> Windows XP (latest patches)
> 1.70 GHz, 512 MB memory:
> 6 hours 25 minutes 57 seconds
Windows is very slow in starting new processes if compared to any Unix
system (especially if compared Windows + 512 MB and Unix + 1 GB). In
cygwin starting new processes even slower because for some reason
emulating fork() involves starting 2 processes one of which dies
immediately. And bash scripts use processes a lot especially with Unix
paradigm when for each small action you start new program (like sed,
awk, test, true and whole lot of others). Thus bash scripts on cygwin
will be slow unavoidably.
But I'm digressing. This is subject for some other mailing list. :)
Pavel
On Fri, Sep 18, 2009 at 3:26 AM, John <jhy...@earthlink.net> wrote:
> Pavel Ivanov wrote:
>>> At least I think that is what you suggest, and think it just
>>> may work! But I could be wrong!
>>
>> Yes, that's exactly what I suggest.
>>
>> Pavel
>
> It worked! Fortunately I had already parameterized SQLITE3 as a
> preference variable so I could have the same scripts run easily on Mac
> OS and Windows. There are dozens of sqlite3 calls throughout the scripts.
>
> My whole set of scripts that process raw data and load the database by
> reading text files seem to work.
>
> cygwin is as slow as I recall, however. I was writing expense scripts a
> few years ago and abandoned it for MacOS Unix. I moved 100% to Mac OS.
> (except for this project which I want to work on Mac, linux, and
> Windows; my next goal is recoding it in Java with its Swing GUI, but I'm
> just learning Java and Swing, but I'm on my way...).
>
> Observed elapsed times on my two notebook computers for the same scripts
> to load the database (using sqlite3 calls and lots of sed and awk
> processing of thousands of lines of input data):
>
> MacBook Mac OS X 10.5.8
> 2 GHz Intel Core Duo
> 1 GB memory:
> 17 minutes 46 seconds.
>
> IBM ThinkPad
> Windows XP (latest patches)
> 1.70 GHz, 512 MB memory:
> 6 hours 25 minutes 57 seconds
>
> Fortunately, sqlite .dump and restoring from the resultant sql will be
> able to be used for most of the heavy lifting when I'm done. Changes to
> the data will come in small increments over time from then on. My dumpit
> and restoreit scripts each take only seconds on both platforms for the
> full set of current data.
>
> Thanks!
>
>> On Thu, Sep 17, 2009 at 1:18 PM, John <jhy...@earthlink.net> wrote:
>>> Pavel Ivanov wrote:
>>>>> I'd rather avoid building sqlite3 under cygwin. I would like
>>>>> to keep as much as possible in native code, compromising only
>>>>> on cygwin to run my scripts.
>>>> And this is root of your problem. Using mix of cygwin-native
>>>> applications with windows-native applications will always have such
>>>> problem.
>>>>
>>>>> When installing cygwin, you it offers you the choice to switch
>>>>> to default text file type to DOS (\r\n). Should I try that?
>>>> Don't do that. This mode of operation is not supported much and not
>>>> recommended by cygwin developers and it reportedly will significantly
>>>> slow down cygwin's operation.
>>>>
>>>>> So I guess my question here is, do any sqlite users here
>>>>> have experience fixing this on Windows for Unix cygwin
>>>>> script calls?
>>>> The major suggestion here: write some "windows native code launcher"
>>>> that will be used for running all non-cygwin applications (this can be
>>>> just function in the script). It will do nothing on unix platforms
>>>> (select your own preferred way of distinguishing it) and it will
>>>> always strip off '\r' from output of running application on windows
>>>> (you can use sed for that). And there's nothing else you can do about
>>>> it.
>>> This sounds like a great idea. I can have all sqlite3.exe calls
>>> "intercepted" by another script call like:
>>>
>>> NumPar=`WINDOWSCALL Program Arguments`
>>>
>>> WINDOWSCALL is the launcher that calls Program sqlite3.exe
>>> with its arguments and strips off any trailing \r's
>>> and returns that string to the caller through stdout,
>>> as to NumPar here. WINDOWSCALL can do nothing on Unix/MacOS,
>>> and fix the string on Windows.
>>>
>>> At least I think that is what you suggest, and think it just
>>> may work! But I could be wrong!
>>>
>>> Thanks! I'll try coding it.
>>>
>>>> Pavel
>>>>
>>>> On Thu, Sep 17, 2009 at 12:26 PM, John <jhy...@earthlink.net> wrote:
>>>>> I am writing some Unix scripts on Mac OS X that use
>>>>> sqlite3. Since the program could be useful to those
>>>>> on Windows, I figured I'd see if they worked under
>>>>> cygwin.
>>>>>
>>>>> A lot of it works, but calling sqlite3.exe from
>>>>> cygwin and returning a string with the value
>>>>> returned from the database seems to attach a
>>>>> "\r" that expr doesn't remove.
>>>>>
>>>>> That is:
>>>>>
>>>>> NumPar=`sqlite3.exe ${DATABASE} "SELECT NumPar FROM citations WHERE
>>>>> X='Key' ;"`
>>>>>
>>>>> NumPar comes back as: "12\r"
>>>>>
>>>>> and
>>>>>
>>>>> NumPar=`expr ${NumPar}`
>>>>>
>>>>> doesn't convert it to integer, as the subsequent test fails because
>>>>> of NumPar being non-integer (it isn't complaining about N, that
>>>>> is integer in the code):
>>>>>
>>>>> if [ ${N} -le ${NumPar} ]
>>>>> ...
>>>>>
>>>>> I can fix this case by:
>>>>>
>>>>> NumPar=`printf '%s' "${NumPar}" | sed 's/[^0-9]//g'`
>>>>>
>>>>> but then other scripts fail later, presumably because of
>>>>> strings with \r on them. (I suppose I can use sed to
>>>>> always remove \r's on every one of these calls, but
>>>>> that seems pretty kludgy, especially since "clean"
>>>>> Mac OS X handles all this "properly" without that.
>>>>> I'm hoping to find an elegant solution.
>>>>>
>>>>> I'd rather avoid building sqlite3 under cygwin. I would like
>>>>> to keep as much as possible in native code, compromising only
>>>>> on cygwin to run my scripts.
>>>>>
>>>>> When installing cygwin, you it offers you the choice to switch
>>>>> to default text file type to DOS (\r\n). Should I try that?
>>>>> My pretty serious objection to that would be that any users
>>>>> already using cygwin with the "correct" default settings would
>>>>> not be able to use the scripts anyway.
>>>>>
>>>>> So I guess my question here is, do any sqlite users here
>>>>> have experience fixing this on Windows for Unix cygwin
>>>>> script calls?
>>>>>
>>>>> Thanks!
>>>>> _______________________________________________
>>>>> sqlite-users mailing list
>>>>> sqlite-users@sqlite.org
>>>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>>>
>>>> _______________________________________________
>>>> sqlite-users mailing list
>>>> sqlite-users@sqlite.org
>>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
