https://bugzilla.wikimedia.org/show_bug.cgi?id=73611

--- Comment #6 from Dan Andreescu <dandree...@wikimedia.org> ---
The slowness of limn is a complicated problem.  It's not the caching, it has
more to do with how it renders all the graphs even if they're not on a visible
tab.  I've tried to solve this but it leads to other problems.  Limn will be
replaced by a dashboarding system that we're trying to design right now.

So it doesn't sound like there's anything simple we can do right now to make
anyone's life better in the short term.  One suggestion, though, is that we
might want to try and make the metadata inferring logic in Limn a little
smarter and able to handle a few more parameters.

Right now, most graphs are added as a graphId to the dashboard.  This graphId
is looked up on the server, fetched and retrieved.  It then loads one or more
datasources which are fetched and retrieved.  Those each load a datafile and
that's why Limn takes forever.

If you add "some valid URL" instead of a graphId to the dashboard, limn will
infer the graph and datasource metadata making it much faster.  So, one thing
we could do is instead of just the URL we could pass some bare minimum
parameters to make it draw what we want like:

{url: '...', type: 'bar|world|line', title: 'Custom'}

Like I say, we're working on a better way to dashboard, but if  that's
happening too slow, this is the most bang for our buck and I'd be happy to help
make it happen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to