Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HDX: Loading speed #301

Open
jteresco opened this issue Dec 28, 2019 · 10 comments
Open

HDX: Loading speed #301

jteresco opened this issue Dec 28, 2019 · 10 comments

Comments

@jteresco
Copy link
Contributor

We need to figure out ways to improve loading speed for larger graphs in HDX.

@michihdeu
Copy link
Collaborator

http://forum.travelmapping.net/index.php?topic=215.msg17130#msg17130
@yakra wrote:

My aging computer takes a bit longer to render the graphs, and then pan/zoom around, primarily due to the number of point markers that need to be drawn.
One thing that I find helps:
I first open up the District of Columbia graph, then deselect "Show Markers".
Then I open up whatever graph I'm actually interested in. It renders a lot faster without the markers being drawn at first.
I pan/zoom to the location I want to examine (which goes faster with just the polylines onscreen), and then reselect "Show Markers".

@yakra
Copy link
Collaborator

yakra commented Dec 29, 2019

http://forum.travelmapping.net/index.php?topic=215.msg17139#msg17139
@michihdeu wrote:

I think it was (much) better last spring and that it got very slow due to the summer work. Sure, there are a lot of improvements but the performance suffered. I don't know, maybe it's just my feeling or just an issue on my end caused by a firefox update or whatever. Loading the GA graph takes about 15s here.

That was my experience as well. Seems I noticed things really slowing down at the time traveled graphs were implemented.

I think that yakra's desciption helps to find the slow element. It seems to be markers (and/or data for their info window)?

It's not just the markers, though; the slowdown was all-around. Loading NY-regions-collapsed.tmg just now, without markers, took ~90s on BiggaTomato.

@Tygor-LLC
Copy link
Collaborator

My understanding is that the speed went down due to our summer work on the project, so sorry about that. My best guess is the custom title tags that I implemented. Due to the nature of everything going on, I had to use JS to relate classes to make them dynamic, which seems to slow down everything by a lot. The bigger the graph, the more custom title tags that need be created and correlated on the back-end.

My suggestion for a fix (if this is indeed the issue) is to create a checkbox on the front page to set a boolean to disallow custom title tags, and just use the normal hover effect ones.

@michihdeu
Copy link
Collaborator

michihdeu commented Dec 29, 2019

Thanks! No need to apologize, there were a lot of improvements!

From @yakra

I just tried GA. Twice. 1st time took 2.5 minutes (unless I DERP DERP DERP read my stopwatch wrong); 2nd time took 3.5 mins.
Seems a bit odd, compared to NY, as there are fewer vertices & fewer edges. Maybe it's because there are many more concurrencies in GA, which have to be parsed from longer edge name strings, containing more commas. But anyway...

My loading times of collapsed graphs (always closed old HDX, new TAB with new HDX instance:
GA: 22s
NY: 29s
ENG: 290s

No parallel activity on my PC (I watched football on TV while waiting for the ENG graph, Reds vs. Wolves, English Premier League 😄)

@yakra
Copy link
Collaborator

yakra commented Dec 29, 2019

What are the custom title tags, and how do they work?

@Tygor-LLC
Copy link
Collaborator

So the custom title tags replace the default title attribute of HTML. One of the goals was to make them a little easier on the eyes. This issue with this being that you cannot customize the title attribute and make it go outside of the container it is in. To get around this, I linked unique class attribute names of the object on screen, and a custom text box. Alongside a js function of hover, it achieved the goal of copying a title attribute, just to our needs.
hdxtagExample

Above is an example of the mouse on one of those objects associated, and in the green is the actual title tag. Below is an example of the generated html for when a map is first loaded (using the ESP-AN-region).
hdxtagExample2

As you can see, anything with data-title as well as Atitle# is an object associated with a custom title tag. It had to be done this way as ID's must be unique, but we also needed to allow for more class tags so we had to have identification of the objects (and giving them an ID for it wouldnt work as some of the require other IDs already). This map used has 1271 waypoints and 1358 connections meaning it has over 3000 custom tags (and by association js functions) just on startup.
hdxtagExample3

There is more manipulation by a lot of JS that actually change around attributes and the like, but this is the jist of it. It is written so (and it may be a little different since I havent seen it in a few months) a custom attribute (I believe custom-title) on the backside works just like title would.

Lastly, every time something new pops up, new titles must be created to allow for the dynamic nature of METAL. This isnt an issue when the map is running algorithms anymore as it is relatively quick by itself. It WAS an issue with running finish map to end as it tried to do all of them at once, but was fixed by disallowing creating tags, as many (likely up to thousands) were done away with and never would have been seen anyway. Since JS is client side, it would definitely explain for the super slow load time, esp on older machines.

@yakra
Copy link
Collaborator

yakra commented Dec 29, 2019

Since JS is client side, it would definitely explain for the super slow load time, esp on older machines.
Yup. MATE System Monitor shows a couple short blips of network activity, and then I have one CPU core redlined for a good while.

I recently installed UbuntuMATE 18.04 LTS on a Xeon E5-1230 machine. Been meaning to check out HDX performance but have not done so yet. Compared to my Core 2 Quad Q6600 desktop, more clock speed + more memory bandwidth (+ a somewhat newer architecture?) should speed things up.

titles must be created to allow for the dynamic nature of METAL.

I'm less familiar with algorithm visualizations; haven't played around with that a great deal. So I'm not sure to what degree this is needed as something for the METAL side of things.

It WAS an issue with running finish map to end as it tried to do all of them at once, but was fixed by disallowing creating tags, as many ... were done away with

Are the custom titles, and/or the green custom text boxes, still needed for METAL?

This map used has 1271 waypoints and 1358 connections meaning it has over 3000 custom tags (and by association js functions) just on startup.

...or could they be done away with now? Or at least simplified?
Seems this could be fairly intensive.

@yakra
Copy link
Collaborator

yakra commented Dec 30, 2019

Loading NY-region-collapsed.tmg takes ~30s, with or without makers, on the Xeon E5-1230 machine.

@jteresco
Copy link
Contributor Author

@yakra If you have a chance and the same hardware is available, could you see how long NY-region.tmg takes to load on that same machine in the current HDX? Last summer's UI design changes might have improved things, but I'm not sure.

@yakra
Copy link
Collaborator

yakra commented May 29, 2022

~18.4s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants