Mark Waddingham wrote
> Each paragraph has at least one style run - even if no styles are
> applied so this is a general thing.
>
> Most of the text in your generated test (data) stack was unstyled anyway
> (as it uses 'the text of' to replicate the data) so minimizing those API
> calls should
On Mon, Apr 13, 2020 at 7:48 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2020-04-13 07:06, Trevor DeVore via use-livecode wrote:
> > Will this caching of the DPI setting affect accessing the styledtext
> > property in general on Windows or will it only affect
On 2020-04-13 07:06, Trevor DeVore via use-livecode wrote:
Will this caching of the DPI setting affect accessing the styledtext
property in general on Windows or will it only affect calls to it
during
saves?
I did a quick test:
- 'the styledText of' is unaffected
- 'the effective
On Mon, Apr 13, 2020 at 12:58 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2020-04-13 02:23, Neville Smythe via use-livecode wrote:
> > But no, it shaved only 1 second off a 7 second save for styled text
> > (elderly MacPro running Windows 10 VM) So your engine
On 2020-04-13 02:23, Neville Smythe via use-livecode wrote:
But no, it shaved only 1 second off a 7 second save for styled text
(elderly MacPro running Windows 10 VM) So your engine modifications
must be having a much wider effect, not just on reducing the 3 API
calls for styled as opposed to
Mark Waddingham wrote
> There appear to be two reasons for the difference:
>
> 1) When saving each style run (block) in a field the engine is making
> three Win32 API calls.
>
> 2) The saving method uses (and always has used) direct Win32 system
> calls to manipulate files without any
Mark, you are a freaking computing god! (small G).
Bob S
> On Apr 11, 2020, at 8:41 AM, Mark Waddingham via use-livecode
> wrote:
>
> On 2020-04-11 13:54, Neville Smythe via use-livecode wrote:
>> Sorry Brian, I uploaded from the wrong folder. Here is the update test
>> set. But the only
Well that would explain why my Datagrid heavy application is a pig saving on
Windows!
Bob S
> On Apr 10, 2020, at 8:46 AM, Brian Milby via use-livecode
> wrote:
>
> I'm going to be that guy who replies to himself...
>
> I just imported a 500kb image to the card, removed the text from the
Awesomeness! I really appreciate all the posting on this. It was informative to
observe the process even if I didn’t participate.
--
Scott Morrow
Elementary Software
(Now with 20% less chalk dust!)
web https://elementarysoftware.com/
email sc...@elementarysoftware.com
booth
On 2020-04-11 16:41, Mark Waddingham via use-livecode wrote:
Anyway, the patches I've made are quite rough at the moment, but I'll
endeavour to submit them as PRs in the next few days :)
I've pushed a WIP PR with the changes I made to get the results
mentioned in my last email - it is here
On 4/11/20 8:41 AM, Mark Waddingham via use-livecode wrote:
After adding a very simple write buffer to the Win32 implementation of
the system file stream class we have. I got:
- Windows 10 (VM) [ Community 'develop' ] - 0.4s
Anyway, the patches I've made are quite rough at the moment, but
On 2020-04-11 13:54, Neville Smythe via use-livecode wrote:
Sorry Brian, I uploaded from the wrong folder. Here is the update test
set. But the only difference is that you don’t need to hold down the
shift key to see the binary save timing.
I did 3 additional tests this morning and believe that the issue lies
somewhere in the de/encoding of text or the way that text is streamed to
the file. My additional tests were using a non-shared text field (due to
the way the text of a shared field is stored in memory, was wondering if
that was
Sorry Brian, I uploaded from the wrong folder. Here is the update test set. But
the only difference is that you don’t need to hold down the shift key to see
the binary save timing.
https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
I just ran another set of tests with a much smaller image.
Text: 5.85s / 0.032s / 8.183708MB
Image: 0.211s / 0.034s / 9.29539MB
One other thing to try tomorrow is to use an individual text field on each
card instead of a shared group. I tried to download the update, but still
got the original
I have an interest in this topic, and even some ideas, but I’ve been swamped
with other demands and not able to read every post. Is there a short way to say
where you are at with the discussion, or a test script that will show a problem?
___
> On 11 Apr 2020, at 2:00 am, Brian Milby wrote
>
> I just imported a 500kb image to the card, removed the text from the field,
> created 300 cards.
> 0.756 seconds normal (171MB). 1.124 from a variable. (image instead of
> text)
> 8.311 seconds normal (8.2MB). 0.047 from a variable. (original
Brian Milby wrote:
> I'm going to be that guy who replies to himself...
>
> I just imported a 500kb image to the card, removed the text from the
> field, created 300 cards. 0.756 seconds normal (171MB). 1.124 from a
> variable. (image instead of text) 8.311 seconds normal (8.2MB). 0.047
> from
I'm going to be that guy who replies to himself...
I just imported a 500kb image to the card, removed the text from the field,
created 300 cards.
0.756 seconds normal (171MB). 1.124 from a variable. (image instead of
text)
8.311 seconds normal (8.2MB). 0.047 from a variable. (original text)
That's a good question. It has been over a year since I looked at that
code, but I can't think of anything in the serialization piece that would
be an issue. That code is all common (writing to a file buffer). I did
not look at the actual platform file code though - could be something
there.
Earlier I wrote:
> Bob Sneidar wrote:
>
> >> On Apr 8, 2020, at 11:16 PM, Richard Gaskin wrote:
> >>
> >> Better still, see the last comment on that page. :)
> >>
> >> It kinda fits Brian's observation about how the stack file is
> >> written in a series of small writes, one per object.
>
Bob Sneidar wrote:
>> On Apr 8, 2020, at 11:16 PM, Richard Gaskin wrote:
>>
>> Better still, see the last comment on that page. :)
>>
>> It kinda fits Brian's observation about how the stack file is
>> written in a series of small writes, one per object.
>
> Yes, but I have saved stacks with
Are we saying we can use binFile to save stacks as opposed to the normal way?
With no side effects??
Bob S
> On Apr 8, 2020, at 7:04 AM, Bob Sneidar wrote:
>
>> put url ("binfile:") into tData
>> put the long seconds into t
>> put tData into url ("binfile:"& fName)
>> put the long
Yes, but I have saved stacks with both Defender and Kaspersky disabled. In our
case I do not think that is the entire issue.
Bob S
> On Apr 8, 2020, at 11:16 PM, Richard Gaskin via use-livecode
> wrote:
>
> Better still, see the last comment on that page. :)
>
> It kinda fits Brian's
-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Neville Smythe via use-livecode
Sent: Thursday, April 09, 2020 1:08 AM
To: use-livecode@lists.runrev.com
Cc: Neville Smythe
Subject: Re: Go to card has become slow
I have updated the SlowSave test stack with Richard's
The speed difference with stack files seems to be that there's high
overhead for each write on Windows 10, and stack files are written on a
series of small writes.
Given this, which would make more sense?:
a) Serialize objects to one buffer in memory
and flush to disk in one write
Neville Smythe wrote:
> I have updated the SlowSave test stack with Richard's enhancement to
> also show the time to save the binary data (no need to use the shift
> button)
>
> https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
>
> Pleased to see everyone is seeing the
I have updated the SlowSave test stack with Richard's enhancement to also show
the time to save the binary data (no need to use the shift button)
https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
Pleased to see everyone is seeing the problem at last, it doesn’t seem to
Richard:
OK, so my impression, that LC saving a (binary) file on Windows 10 is not the
problem, is correct, as you deduce it lies in the serialisation of the stack.
Now why would that be platform, indeed OS, dependent? Could the LC
cache/virtual memory settings be different for Windows 10 from
On my Win10 Dell (i5):
6.154 to 6.806 without shift
0.036 to 0.15 with shift
This is measuring a difference in doing a bulk 8MB write with a streamed
write of the stack to the file piece by piece. Internally, each object is
serialized and written to the file buffer in turn. So the question
Saving the 300 cards 8.x MB stack on a 2017 MacBook Pro SSD:
0.127276 seconds
Same stack saving as binfile:
0.013656 seconds
Kind regards
Bernd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe,
Ralph DiMola wrote:
> 0.033 shift key down
> 28-30 seconds shift key up.
It's almost like the stack file takes longer, if only the difference
were more clearly evident. :)
I'll include your results with the test data I'll add to the report.
Thanks for running that.
--
Richard Gaskin
, 2020 1:46 PM
To: use-livecode@lists.runrev.com
Cc: Richard Gaskin
Subject: Re: Go to card has become slow
Ralph DiMola wrote:
> LC 9.5.1
> Win 10 Hyper-V VM with 8 processors assigned Stack and data on smb
> served by VM host.
> Host ==> i7 6700 3.40Ghz 16 Gig
>
> sa
Ralph DiMola wrote:
LC 9.5.1
Win 10 Hyper-V VM with 8 processors assigned
Stack and data on smb served by VM host.
Host ==> i7 6700 3.40Ghz 16 Gig
saving data took 38.46 seconds
8.183708 MB
LC 9.5.1
MacBook Pro Early 2011 OSX 10.13.1 16 Gig
Stack and data on smb served by the
11:17 PM
To: use-livecode@lists.runrev.com
Cc: Neville Smythe
Subject: Re: Go to card has become slow
Richard
Here is a link to the test stack for testing the speed of save stack
https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
I don’t know why the test stacks I suppl
Interesting results Richard. I hope the mothership is monitoring this thread.
I’ll give the test a go later today. I have to go out (believe it or not) to
some customers this morning and early afternoon.
Bob S
> On Apr 7, 2020, at 10:56 PM, Richard Gaskin via use-livecode
> wrote:
>
>
Great test set, Neville. Thanks for posting that link.
The hardware on my Linux and Win boxes is so different I don't have a
strong opinion there. But I did modify your main test script to see what
I might learn from isolating the file I/O from the stack serialization:
on mouseUp
put word
Richard
Here is a link to the test stack for testing the speed of save stack
https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
I don’t know why the test stacks I supplied disappeared from the QC bug report.
You need the SlowSave.livecode and the data.livecode stacks.
Richard, I can verify that my mainStack is pretty big in terms of objects and
code. When I create a standalone for Windows however, it breaks out all the
substacks into individual stacks, and the saving just the mainStack in a
Windows standalone still takes longer than saving the entire
Neville Smythe wrote:
> Richard wrote
>> Bob Sneidar wrote:
>>
>>> In review, I tested saving stacks on a standalone Windows
>>> Workstation, a VMWARE VM on a very robust server host, a
>>> Parallels VM on a workstation and my Mac. As I am saving
>>> the stack, I am watching the folder the stack
Richard wrote
> Bob Sneidar wrote:
>
>> In review, I tested saving stacks on a standalone Windows Workstation,
>> a VMWARE VM on a very robust server host, a Parallels VM on a
>> workstation and my Mac. As I am saving the stack, I am watching the
>> folder the stack is in. I see the tilde
Bob Sneidar wrote:
> On Apr 6, 2020, at 9:28 AM, Richard Gaskin wrote:
>
>> Your application writing data to disk is a very different thing from
>> Windows Desktop Explorer automatically refreshing a directory view.
>
> Control doesn’t return to the application until the tilde version goes
>
You are testing low level file operations. I am testing the saving of a
Livecode stack. I don’t think this test applies.
Bob S
On Apr 6, 2020, at 9:28 AM, Richard Gaskin via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
on mouseUp
put the long seconds into t
write "somedata"
Control doesn’t return to the application until the tilde version goes away.
On Apr 6, 2020, at 9:28 AM, Richard Gaskin via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
Your application writing data to disk is a very different thing from Windows
Desktop Explorer automatically
Bob Sneidar wrote:
> In review, I tested saving stacks on a standalone Windows Workstation,
> a VMWARE VM on a very robust server host, a Parallels VM on a
> workstation and my Mac. As I am saving the stack, I am watching the
> folder the stack is in. I see the tilde version pop up and go away.
On Apr 5, 2020, at 11:18 AM, Bob Sneidar via use-livecode
wrote:
>
> I don’t think LC accepts multiple statement transactions at all, does it?
I’d be dead int the water if it didn’t. ;)
I’m flat out *dependent* on these—opening a debtor in my software requires
several hundred entries to be
Hi Richard.
In review, I tested saving stacks on a standalone Windows Workstation, a VMWARE
VM on a very robust server host, a Parallels VM on a workstation and my Mac. As
I am saving the stack, I am watching the folder the stack is in. I see the
tilde version pop up and go away. On Mac it’s
I don’t think LC accepts multiple statement transactions at all, does it?
Bob S
On Apr 5, 2020, at 11:00 AM, doc hawk via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
If server performance is at all an issue, SQLite may be the wrong choice.
It has a kind of, very reluctant,
If server performance is at all an issue, SQLite may be the wrong choice.
It has a kind of, very reluctant, simultaneous access that the developers warn
you not to use.
They suggest PostgreSQL for heavy loads.
I use SQLite within the application (the in-memory access is blindingly fast),
and
Bob Sneidar wrote:
> Thanks Terry I did the same thing. The focus is on server performance,
> not client. What I gleaned is that for an individual transaction, the
> difference between a transactional select statement and non is
> indistinguishable to the end user.
The rubric I was given back
Thanks Terry I did the same thing. The focus is on server performance, not
client. What I gleaned is that for an individual transaction, the difference
between a transactional select statement and non is indistinguishable to the
end user.
Also, filtering out any save operations (including
There is an interesting debate here as to whether it is necessary or not to
wrap select statements in transactions for optimisation:
https://stackoverflow.com/questions/7349189/optimizing-select-with-transaction-under-sqlite-3
Mark, you may have answered why it is my Forms Generator app is running so slow
on Windows. I don’t use transactions and I make multiple queries for most
transactions.
Bob S
On Apr 3, 2020, at 1:42 AM, Mark Waddingham via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
On
What may help in the future to eliminate possible script issues, is to use a
text editor that has the capability of comparing two scripts and showing you
the difference. Most of the code editors have addams that will do this.
Bob S
On Apr 3, 2020, at 1:25 AM, Terence Heaford via use-livecode
...@lists.runrev.com] On Behalf Of
Terence Heaford via use-livecode
Sent: Friday, April 03, 2020 8:55 AM
To: How to use LiveCode
Cc: Terence Heaford
Subject: Re: Go to card has become slow
I have now copied the modified scripts from the project version that was slow
and reapplied them to the previous version
I have now copied the modified scripts from the project version that was slow
and reapplied them to the previous version which was running fast.
Applying the modified scripts has not resulted in any slowdown of the version
they have been applied to.
So, I cannot understand why the project
On 2020-04-03 09:25, Terence Heaford via use-livecode wrote:
Fortunately I have Time Machine running on my mac.
I have gone back to a previous copy from the 01 April 2020 and this
project is running at full speed.
I have made no modifications to the underlying functionality of this
project
Fortunately I have Time Machine running on my mac.
I have gone back to a previous copy from the 01 April 2020 and this project is
running at full speed.
I have made no modifications to the underlying functionality of this project
other than some modifications to SQLite
scripts to improve
I have seen delays when going to a card containing a large image with Resize
Quality set to “Best”. It was more of an issue on a mobile device, but it’s
worth looking into.
Devin
> On Apr 2, 2020, at 1:27 PM, Terence Heaford via use-livecode
> wrote:
>
> I have a project that opens at a
Also, any audio/video files that load?
> On Apr 2, 2020, at 1:46 PM, Pi Digital via use-livecode
> wrote:
>
> Hi Terry
>
> Are there any big images on the first card? Any layer effects or blend modes?
> Anything graphic based that could be attributed to the slow down.
>
> Sean Cole
> Pi
>
Hi Terry
Are there any big images on the first card? Any layer effects or blend modes?
Anything graphic based that could be attributed to the slow down.
Sean Cole
Pi
> On 2 Apr 2020, at 20:27, Terence Heaford via use-livecode
> wrote:
>
> I have a project that opens at a particular card.
I have a project that opens at a particular card.
When I go to another card (any card) it’s very snappy.
When I return to the original card (from any card) I have noticed a second or
two delay before it happens.
There would appear to be nothing in any script that would account for this.
Can
62 matches
Mail list logo
