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

BuildUrl() Slowness #71

Open
mpwoodward opened this issue Mar 2, 2012 · 2 comments
Open

BuildUrl() Slowness #71

mpwoodward opened this issue Mar 2, 2012 · 2 comments

Comments

@mpwoodward
Copy link

I was just working through a performance issue with a couple of co-workers, and we narrowed things down to BuildUrl() being slow. Realizing the answer may be a simple "don't do that" I figured I'd pass this along anyway.

This is on Mach-II 1.8.1.

We have a query with about 50 records in it, and we're looping over that spitting out rows in an HTML table. We stripped out anything fancy (IOW no datatables/tablesorter kind of stuff enabled) so it's just looping over the query and creating table rows.

What triggered us looking into this was that to render that page with only 50 records was taking about 4 seconds, and we tried another query with 200 records and it'd take about 10 seconds to render the page. So we went through the usual troubleshooting steps to eliminate the database and everything else up and down the chain.

Each cell of each row has an onclick event, and there's 5 cells per row. For the onclick event BuildUrl() was being used, so that's 250 BuildUrl() calls in the table with 50 records.

As I said with BuildUrl() it was taking about 4 seconds to render the page, but when we removed BuildUrl() and hard-coded the URL for the onclick event (meaning the only change we made was to remove BuildUrl() and everything else stayed the same), the time went down to about 3 ms, so about a 1000X difference.

Again maybe the answer is "don't use that many BuildUrl() calls" but I wanted to pass it along in case it was something that needed to be looked into.

@maestrofjp
Copy link
Member

There definitely could be some performance optimisations here...there is a lot of string concatenation going on here to do this as well as checking for other items.

Sometimes I do this at the top of the process:

baseUrl = BuildUrl("SomeEvent", "id="${replace.id}")

In the loop, do a:

#ReplaceNoCase(variables.baseUrl, "${replace.id}", qryRead.id)#

In essence, I'm creating a placeholder and replacing it at runtime (or as I almost called it...funtime).

Let me look into it.

@maestrofjp
Copy link
Member

We can probably do some sort of caching of generating URLs I think.

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

2 participants