Thanks Mark, now I get it!
Ben
On 12/09/2021 12:09, Mark Waddingham via use-livecode wrote:
On 2021-09-10 19:10, Ben Rubinstein via use-livecode wrote:
The other was
The only caveat is that it might cause apps mutating lots of medium->large
strings concurrently to take up more memory in
On 2021-09-10 19:10, Ben Rubinstein via use-livecode wrote:
The other was
The only caveat is that it might cause apps mutating lots of
medium->large strings concurrently to take up more memory in
general... > ... (and any issue arising from that could be resolved by
moving to the 64-bit
Ah yes, the cheese thing. I so wish I had saved that thread, but I may have
needed an extra backup drive to do it. So listen, and ye shall hear.
Long, long ago in the olden days, before there was a forum, before 64-bit
apps, back when the QCC reports numbered in the lower hundreds, someone on
I thought Mark was misremembering Emmental when he said Edam (they do
start with an E) but I believe
Venezuelan Beaver Cheeses is probably a better analogy as it has many
holes caused by the beavers' sharp incisors.
and is a bit of a mystery (very difficult to acquire) as is the workings of
Yes, it did mention cheese... but it was entirely on topic and about LiveCode.
(How could Mom not approve.)
--
Scott Morrow
Elementary Software
(Now with 20% less chalk dust!)
web https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth1-360-734-4701
I’m going to propound on the politics of holey cheese makers in a moment!
Sent from my iPhone
> On Sep 10, 2021, at 11:16, J. Landman Gay via use-livecode
> wrote:
>
> You're talking about cheese. I'm telling Mom. Nyah.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
>
You're talking about cheese. I'm telling Mom. Nyah.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On September 10, 2021 8:42:48 AM Trevor DeVore via use-livecode
wrote:
On Fri, Sep 10, 2021 at 8:15 AM Mark Waddingham via
Hi Mark,
Thank you for this, very promising.
Only two things puzzled me. One you've already addressed when you corrected
the specified cheese.
The other was
The only caveat is that it might cause apps mutating lots of medium->large
strings concurrently to take up more memory in general... >
Cheddar, Edam and Swiss!
Very daring references on this list.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
On Fri, Sep 10, 2021 at 8:15 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2021-09-10 14:06, Mark Waddingham via use-livecode wrote:
> > The windows heap is much more prudent than UNIXy counterparts it would
> > seem - where UNIX heaps will happily leave plenty
On 2021-09-10 14:06, Mark Waddingham via use-livecode wrote:
The windows heap is much more prudent than UNIXy counterparts it would
seem - where UNIX heaps will happily leave plenty of free space (which
the heaps know about and thus can re-use), Windows appears to avoid
that like the plague
On 2021-09-02 18:38, Mark Waddingham via use-livecode wrote:
We will endeavour to fix for 9.6.5-rc-1 (due 'real soon now'!).
So I have been prodding the windows 'accumulating large strings' speed
problem this week (in amongst other things).
It is definitely memory allocation causing the
I'm very much hoping that Mark W might magically fix this in 9.6.5.
But in the meantime FWIW, the place where this was really hurting (in a script
that took 8 minutes under LC6, was taking 8 hours under LC9, but I've
gradually tamed it down to under an hour by buffering the large
I am going to say no, because you still have to traverse the file once to get
it into sqLite, then do the sort, then write out the file when done. I might be
mistaken, the subsequent SQL sort may make up for lost time. Using a memory SQL
really shines when you need to make multiple passes at
Whilst waiting for a fix, would a temporary solution be to use sqlite to
create an in-memory database and let sqlite do the sorting for you?
Regards, Bernard.
On Mon, Aug 30, 2021 at 8:23 PM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Thanks to Mark Waddingham's
On 2021-08-30 20:22, Ben Rubinstein via use-livecode wrote:
Thanks to Mark Waddingham's advice about using a buffer var when
accumulating a large text variabel in stages, I've now got a script
that took 8 hours under LC9, and (8 minutes under LC6) down by stages
to just under 1 hour under LC9.
Thanks to Mark Waddingham's advice about using a buffer var when accumulating
a large text variabel in stages, I've now got a script that took 8 hours under
LC9, and (8 minutes under LC6) down by stages to just under 1 hour under LC9.
However I have some remaining issues not amenable to this
Thank you Mark!
Using a buffer indeed essentially solves the problem (at least for this
example!).
Because I may have to use this in a bunch of places, I made my life easier by
putting it in a command using variables passed by reference. Because I'm
almost invariably appending a line at a
On 2021-08-25 18:15, Ben Rubinstein via use-livecode wrote:
I simplified it down to this (pointless) loop which just rebuilds a
table one line at a time:
local tNewTable
repeat for each line tRow in tWorkTable
put tRow & return after tNewTable
end repeat
with these results:
Thanks Curry.
In fact (apologies I didn't make this clear in my already too-long email) it
really is just the accumulating of text, at least in this instance, that's the
issue. After I added a test on each extracted (i.e. looped over) line to see
if it was "strictly a binary string", and
Hi Alex,
Thanks for responding. It's an interesting idea and I may have to try it.
But I've got 5,000 lines of script that has evolved over 20 years, so I really
don't want to have to rewrite it all! It seems to me that there is an
identifiable problem here; something that is happening on (at
Ben:
> But the key thing is: for this task, LC9 is
> dramatically slower on Windows!)
> Have others seen something like this?
Generally: Yep, I've seen plenty of slowdowns.
On both Windows and Mac, depending on the task.
Specifically: I'd like to test this later;
still recovering from two
Crazy idea - totally untried (sorry, I don't have a Win machine)
put 1 into tLineCount
repeat for each line tRow in tWorkTable
put tRow into tNewTable[tLineCount]
add 1 to tLineCount
end repeat
combine tNewTable using CR
Alex.
On 25/08/2021 18:15, Ben Rubinstein via
Some 20 months ago, I reported that I was in a situation where an app written
in 6.7 needed to be updated to access 64bit drivers, which meant updating to
9.5 - which displayed horrifying increase in processing time.
In fact I was able to put off the evil day - but now it has returned, and
24 matches
Mail list logo