Need help testing a nagging IDE "bug"

Can anyone help me test a bug when saving a project in text format? For me, if I’ve modified a class/window/module with a lot of code in it, saving to text format (.xojo_project) takes a lot longer than saving to binary or XML. I could just work in binary and save out to text format when I want to do a commit, but I’ll inevitably work in the wrong copy at some point and lose work.

I’ve filed bug reports and they always get closed as not reproducible or fixed, but nothing changes for me in subsequent releases… maybe there’s something odd about my system?

If you want to help,

  1. Download this project file (32k code lines in 16 methods)
  2. Save-As xojo_xml_project. Note the time required to save.
  3. Save-As xojo_project (text format). Note the time to save
  4. Save-As xojo_binary_project. Note the time to save.
  5. Post back with Xojo version, OS version, System type, HD type, and save times.

If it really IS my system, maybe I can change something. This is a major impediment to working in Xojo… if others see the same, I’ll include the results in my next bug report…

Here’s my results:

Xojo 2019r1.1
macOS 10.14.5
MacBook Pro Retina mid-2012 2.7Ghz i7
Samsung SSD 860 EVO mSATA 500GB

xojo_xml_project: 2 seconds
xojo_project: 1 minute 40 seconds
xojo_binary_project: < 1 second

Thanks in advance.

uh <https://xojo.com/issue/55535> says “fixed”
I saw similar results to yours and attached the samples

EDIT :
FYI
Save-As xojo_binary_project. doesnt reformat anything to write to disk since it just stores binary data plus the binary tags to identify things. But it rewrites the entire thing.

Save-As xojo_xml_project. - this saves as binary in memory then converts the binary to xml and writes that to a file.
Should be slightly slower than binary but faster than text. Has the downside of temporarily requiring extra memory for the internal binary + xml copies which are eventually disposed of

Save-As xojo_project (text format). rewrites 100% of whatever file has been changed. And since it also indents etc this requires running some level of code that does the reformatting (to indent properly)

There’s not much you can do besides - keep methods short. Save often.
That way the amount of rewriting is minimized on each save.

Or save once a day and get a coffee when you do :stuck_out_tongue:

Yeah, this goes way back <https://xojo.com/issue/42245> That one’s “fixed” too…

The latest case demonstrated a different issue than the previous cases as far as Ican see (and recall)
So its entirely both are indeed fixed

We’ll just have to wait & see
Either way Text will be slowest because of the sheer volume of data that for any single class is written as the formatted form that text files are. Neither binary or XML do that work

Careful what you hope for. We may find that instead of speeding up the VCP save, they slow down the binary and XML saves o_O !

[quote=437772:@Norman Palardy]The latest case demonstrated a different issue than the previous cases as far as Ican see (and recall)
[/quote]
No, exact same behavior.

[quote=437772:@Norman Palardy]We’ll just have to wait & see
[/quote]

I had hoped to see something in 2019r1.1 since the latest report was closed before that. Maybe next release… it’s been like this back to at least 2014 so what’s one more release…

I think I remember you having fixed the old report in a beta, but it never made it into the release version afaik.

[quote=437781:@jim mckay]No, exact same behavior.
[/quote]
I should have said “a different cause of the behaviour”

2019r1.1 ws focused on a few really egergious bugs - and one feature (???)

If it never made it into the specific release it for sure woudl have been in the next
There’s no way that could have been avoided

They’d have to really try to do that so I doubt that would, or could, happen
I have a pretty good idea off the top of my head from the last samples on the case I noted what to go looking for … but … since I dont work there any more …
We’ll see what they found and fixed since it was specific to saving those text files with lots of lines in those long methods that had to be rewritten

Xojo 2019r1.1
Windows 10
AMD Ryzen 7 1700X (8 core 3.8Ghz
Crucial SSD 750 GB Sata3
Mainboard Asrock X370 Killer SLI

xojo_xml_project: <1 seconds
xojo_project: <30 seconds
xojo_binary_project: < 1 second

is a fast SSD drive. EVO 860 drives are a preferred drive for the gaming community due to their speed.

if this is an MX550 series, it is a fast general purpose drive. and that is what I us in all my machines.

so neither of these drives are the slow down. they are “faster” than the “average drive” out there in use. Fastest would be NVMe drives using an NVMe interface (rare to find).

I doubt its the “fast drive” thats the issue
Xojo uses old API’s that deal with HFS+ fine but suck like hell on APFS would be one - that might show in the samples
I suspect this has far more impact

No this is a MX300, an older type. I guess about 3 or 4 years old

Xojo 2019r1.1
Windows 10
i9-9900X 10 Core @ 4.4GHz
Samsung 960 Pro 2TB

xojo_xml_project: instant
xojo_project: <15 seconds
xojo_binary_project: instant

Its a single thread speed issue probably as Norman mentioned due to massive string manipulation as I see one logical CPU max out during the process and the disk is hardly touched.

It’ll be nice to see how this performs in 2019r2

[quote=437888:@JulianS]It’ll be nice to see how this performs in 2019r2

[/quote]

Agreed. I’ll just wait for the next release and see how things look.

I’ll have to upgrade my machine at some point too… 7 years is about the limit for a Mac before it’s relegated to the email/youtube pile…

Xojo 2018r3
macOS 10.14 latest beta
MacBook Air i5
Harddisk: APPLE SSD SM0256G
APFS

Timing:
XML: progress window barely visible
binary: progress window not visible
text: 32 seconds

APFS always sucks in regards to speed.

Apfs has all sorts of performance issues.

@jim mckay the mx300 is still even with or slightly above the “average” disk (JD/SSD/NVMe) performance when averaging across all “in use” systems today. There is nothing wrong with that drive in performance.

It is true that the mx500 and mx550 are faster but for most people there is no real (perceived) difference.

@JulianS your finding don’t surprise me.

Command line git is slower on apfs than hfs+ or exfat. I had to reformat my raid array from apfs volumes to exfat for my fit repos as there were noticeable speed differences.

Just to be clear, the fix that was submitted for this issue had nothing to do with APFS. The IDE was simply doing a lot of unnecessary work when saving code in text format. That is what we fixed.

Nothing will fix the destruction caused by Apple’s move to APFS …

Using the current API’s for file system work will
Old API’s go through a weird set up that basically runs as a XPC service which has an enormous overhead and performance penalty
Current macOS Api’s for files dont do this so they have no such penalty

[quote=437917:@Greg O’Lone]Just to be clear, the fix that was submitted for this issue had nothing to do with APFS. The IDE was simply doing a lot of unnecessary work when saving code in text format. That is what we fixed.

[/quote]
I’m quoting this so I can like it again.