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?
Save-As xojo_xml_project. Note the time required to save.
Save-As xojo_project (text format). Note the time to save
Save-As xojo_binary_project. Note the time to save.
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
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.
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
[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.
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
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
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.
@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.
@ your finding dont 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.
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.
