Slow to generate application.js

[qume]

When I launch smashing, the first request takes around 30 seconds. It looks like this is when it generates application.js.

Is this normal and expected, and if so are there any known ways to cache and/or speed this up. Restarting the server to re-read jobs scripts makes development slow. I realise I could move jobs out of smashing and have them push data in via the API, but wanted to check first others experiences.

Running Ubuntu 18 on Jetson Xavier NX

[qume]

Apologies for the 'bug' label - it seems to have added it automatically and I can't seem to remove it.

[kinow]

Apologies for the 'bug' label - it seems to have added it automatically and I can't seem to remove it.

Not a problem. let's leave the bug, but add a question too.

[kinow]

With Rails we could simply ask it to precompile the assets for us. But I couldn't find a solution for our Sinatra+sprockets.

Sprockets will process the assets in our javascripts (and others) and combine them, creating an application.js file on the fly. But apparently it took a long time on your environment.

I tried this quick script:

# original: https://stackoverflow.com/a/13863492
require "sprockets"
require "dashing"


assets = Sprockets::Environment.new
assets.append_path File.join(Gem.loaded_specs['smashing'].full_gem_path, 'javascripts')
assets.append_path "assets/javascripts"

task :assets do
    assets["application.js"].write_to "assets/javascripts/application.js"
end

And rake assets produces the application.js but I think I didn't create the sprockets environment correctly. But I think that's the idea, to compile the assets for your dashboard once, and after that the startup time should improve 🤞

[qume]

Great thanks that's definitely a step in the right direction. It ran without errors, and the application.js it generated looks sensible.

However it doesn't display anything, and it's friday evening here, so will have a look next week. Hopefully something simple.

I'm using this as a UI for an embedded device (with minor changes to make tiles clickable), so my off-label use case probably doesn't fit with what the project is designed for. It works great for it though.

[kinow]

@qume could you test with the Rakefile from this PR, please? #190

Feel free to approve the PR if that works for you :-) when merged, future versions of Smashing will include a Rakefile with the generated dashboard project (i.e. smashing new test will have test/Rakefile) that can be used to produce the precompiled application.js. Not generating application.css for now, but we could do that too if it's slow to compile it.

Thanks
Bruno

[kinow]

@qume,

on Jetson Xavier NX

Hijacking this issue for a quick question. Really interesting you used this board/computer. Hadn't heard about it. Looks like a raspberry pi, but with a GPU?

Does it work well (not only for Smashing)? I have a very old Thinkpad that I don't have plans for replacing. But I've been using Blender, and due to my old GPU and its Cuda version, I'm rendering everything with my CPU.

I've been reading about external GPU's and cloud rendering farms as alternatives, but now I'm wondering if I could perhaps use one of these AI/ML computers instead?

Thanks!
Bruno

[qume]

It looks like you're in Auckland. Send me your postal address to luke@reid.org.nz and I'll send you one. I'm using the Xavier NX because I needed a bit more horsepower, and I have a Jetson Nano here you can have.

They work well. Nvidia can be slightly frustrating on the software side, but if you want something small with a bunch of Cuda they are great. Like you say, essentially a Raspberry Pi but with GPU